a matter of scale

Scripting Issues
1

I modeled a scene in blender structured as follows:

- a main node
 |->a_plain_mesh
 |->a_cube_mesh (placed somewhere far from 0,0,0)

I export this mesh in a egg and load as usual as a model and then I scale it like this

    scene=loader.loadModel( 'scene' )
    scene.reparentTo(base.render)
    scene.setScale(3)

all appear visually perfect as I expected. Then I wanna programmatically place above the cube another object and so I supposed to do like this:

      
  sp=self.stage.find("**/a_cube_mesh")
  pos=sp.getPos()
  object_to_place_above.setPos(*pos)

but the object isn’t placed were I was expecting but at a smaller distance from 0,0,0.
Commenting the scene.setScale(3) line became obvious that is a matter of scale 'cos the object position matches now perfectly the cube but I wonder if this is a correct behavior cos that cube is inside an egg model structure where his parent have been rescaled. I guess not but maybe I’m wrong and maybe there is a different way to achieve my goal I don’t know.

2

Yes, this is correct behavior. Node positions are scaled too - not just vertex positions. Otherwise it would be inconsistent behavior.

There’s a solution - call flattenLight after scaling your scene. This applies the transform onto the vertices, and after that you’ll be able to position right.

Alternatively, set the scale of your subnode to 3, or set the positions relative to render:

sp.setScale(render, 1)
# OR:
sp.setPos(render, *pos)
3

the problem is that looks like don’t
I settled up a quick sample to play with that clearly shows this - you can grab it here - I included also the blender source for reference just in case. Press 1,2,3 to scale the scene on the fly by *1, *2 or *3 factor. You’ll see that the red triangle size and position will change visually but the position is reported by the find function without the scale applied. I expect the find function should return the scaled position but actually isn’t so.

4

That is correct, since you’re using getPos() which returns the position relative to the parent.

Use self.spawnpoint.getPos(render) to get the absolute, scaled position - or instead of “render”, any node which is a parent of self.scene/“scene.egg” will work.

PS. Note that your code doesn’t work in 1.7 - remove “.upcastToPandaNode()” to make it work. That function has already been deprecated for a long time, lights are automatically upcast to PandaNodes when necessary.

drwr, could we maybe keep this function, and just issue a warning? I know it’s been deprecated for a long time, and it’s good to eventually remove deprecated stuff, but this breaks kind of every piece of code around. IMHO, Panda could use a bit of backward compatibility.

5

the self.spawnpoint.getPos(render) did the job, thanks

about the deprecated light code I took it off a sample from the official pack- I guess that is a huge source of deprecation and I guess need to stick hands into to clean’em (these days I’m diggin in but so slowly)

6

This method was always automatically generated because DirectionalLight et al multiply inherited from PandaNode and Light. Interrogate will generate an upcastToX() and upcastToY() method whenever there is multiple inheritance (because only in the case of multiple inheritance does the “this” pointer change during an upcast operation).

Now that these classes inherit from LightLensNode instead, which in turn multiply inherits from Light and Camera, this automatically-generated function has been replaced with an automatically-generated upcastToCamera() method instead.

So, there’s no easy way to put this method back. I guess we could write an explicit upcastToPandaNode() method, but all that does is allow people to continue to cut-and-paste code from Panda 1.0 (1.0!) without really understanding what it does. I’d really rather remove this wart from all of the Panda examples. We could put this method in and have it print a warning message, but any code that uses this call is probably also using the old LightAttrib interface, and that warning message has had zero effect on eliminating old usage patterns.

Short answer: I think it’s been officially deprecated for long enough, and it’s time to remove it. I do agree we need more backward compatibility, but not ad infinitum; otherwise we’ll eventually smother under the weight of supporting old interfaces (similar to the problem OpenGL is laboring under).

David

7

Ah, so it appears to be my fault. :slight_smile: Fair enough, I’ll see about modifying the sample programs.