Built-in box visual object has incorrect normals, when created via loading a urdf

[elkmug]

If you create a urdf that uses the built-in visual representation for a box, it works, but the box does not have proper normals. block.urdf in the bullet data folder can be used to demonstrate the problem but you'll probably have to make the size of the block larger or you won't be able to notice the issue, unless you zoom waaay in.

Interestingly, if you create the multibody with createMultiBody, rather a urdf, and set the baseVisualShapeIndex option to -1 to get the built in visual shape, the normals are correct. createMultiBodyLinks.py in examples\pybullet\examples is, well, a good example of this

I haven't had a chance to test the built-in spheres or cylinders, so don't know if they have the same issue or not. Also In the attached image the smaller cuboid on camera left, with correct normals, uses the mesh visual object and is loading a .obj.

-Jeff

[Erwin Coumans]

It is not clear what the problem is. Can you share a simple pybullet Pythons script that shows the problem?

[elkmug]

Attached is a zip of a simple script and it's urdfs.

I included the plane.urdf, plane obj, & plane.mtl
from the bullet data folder so things would run from
wherever you extract this

[Erwin Coumans]

What is 'incorrect' about the normals? I get a similar image than you. What kind of normals would you expect?
The built-in cube likely uses interpolated vertex normals, instead of face normals.

If you want unique normals that point in the face direction,why don't you use Bullet/data/cube.obj?

by the way,

Code: Select all

tStep = 1.0/1000
subStep = 200

print("tStep:"), tStep

p.setPhysicsEngineParameter(fixedTimeStep=tStep, numSubSteps=subStep)

Do you really want to use an internal physics simulation step of 1 / 200.000? substeps divide the provided timestep.

You likely want to use use a substep of 1, when using a simulation step of 1./1000.

[elkmug]

>What is 'incorrect' about the normals?
The normals are smoothing edges that on a cube shouldn't be smoothed.
I don't think anyone would look at the above image and say 'That cube looks correct'

>If you want unique normals that point in the face direction,why don't you use Bullet/data/cube.obj?
Well, I certainly could and have been using the cube.obj, but figured that the built-in version might be more efficient. With a multibody more complex than a single cube you might load that same obj quite a few times. Does pybullet automatically realize it's the same file and create instances rather than a bunch of unique objects? (If so, very cool.)

Also pybullet.createMultiBody does handle the normals of it's built-in box 'correctly', it's seems inconsistent that loading a urdf does not.

The timestep/substeps are indeed wacky, they were from a different experiment where I was pushing around settings to see what would happen and I forgot to change them back.