Panda3d paged geometry?

ModelRoot is the name of the class. The string name of the node is, I believe, the egg filename.

As I said various times before, you can simply call clearModelNodes() and Panda will do it for you.

I just tested it out and you shouldn’t have to do that.


…should suffice. I’m guessing clearModelNodes does the same work behind the scenes…iterates through all children and removes the ModelRoot.

Edit: ninja’d!

I found only this one:

Okay missed that one. Sorry.

I want to add LODing now, but theres a problem with point sprites:
(sorry for the quality)

You should notice the small tree in the middle of the screen though. The thing is, it stays small and not prespective untill you rotate the camera around it for some time. Bug?

from direct.directbase.DirectStart import *
from pandac.PandaModules import *

# render the tree in another buffer and use it as a texture for the point sprites
spritebuffer ="sprite buffer", 512, 512)
spriterender = NodePath("sprite render")
spritecam = base.makeCamera(spritebuffer)
spritecam.setPos(0, -12, 0)
tree = loader.loadModel('media/trees2/fir06_30.mesh.xml.egg')

# make a point sprite nodepath and assign the above texture to it
array = GeomVertexArrayFormat()
array.addColumn(InternalName.make('vertex'), 3, Geom.NTFloat32, Geom.CPoint)
format = GeomVertexFormat()
format = GeomVertexFormat.registerFormat(format)
vertexdata = GeomVertexData('sprite', format, Geom.UHStatic)
vertexwriter = GeomVertexWriter(vertexdata, 'vertex')
prim = GeomPoints(Geom.UHStatic)
geom = Geom(vertexdata)
node = GeomNode('gnode')

sprite = render.attachNewNode(node)
sprite.setTexGen(TextureStage.getDefault(), TexGenAttrib.MPointSprite)

# environment
env = loader.loadModel('environment')


This problem is the same as this:
[A bug with sprites and setRenderModePerspective(True)?)

well im not in this case and its still there

There are occasionally driver bugs with perspective sprites. If you’re seeing a driver bug, you have to set:

hardware-point-sprites 0

but then you’re more limited in the number of sprites you can have before your performance degrades. But if this solves your rendering problem, it proves you have a driver bug and not a Panda bug.



But its not happening with particles. Why?

Honestly, I’ve long since given up on asking “why” a driver bug behaves in a particular way. I’ve seen everything, and only about half of it makes sense.

If you are seeing a driver bug, and it happens in some cases and not in others, I really can’t tell you why. But you’re more than welcome to research it further and see if you can determine what the difference is.


By my knowledge sprite particles work the same way, so i thought theres a small possibilty that panda itself doesnt do everything ‘right’ (maybe theres a workaround code for such bug in the particles sourcecode).

Yes, it’s certainly possible. I’m not aware of anything wrong in there, but you’re welcome to research it and let me know if you find anything. :slight_smile:


I can’t. I think most users here can’t, mostly because we don’t even know C++.

Pshaw. You just successfully constructed an animated character based on little to no documentation and a handful of sample code. You can’t tell me that C++ is beyond you. :slight_smile:

But even still, there might be no reason you need to delve into C++ to research this. The particle system doesn’t do anything other than create GeomPoints with the RenderModeAttrib set on them. If the particle system is rendering correctly, but your own points aren’t, then either something is different with the scene graph between these two cases, or the difference has nothing to do with Panda.


Well I asked tons of questions and I still dont have everything working correctly in that thread, and C++ isnt something you can learn in a weekend, so…

I can just make this assumption: the main difference is that particles are a single geom, but in another thread i also had everything as a single geom, so the only difference would be that the vertices in the particle system’s geom are “dynamic”. Ive already mentioned that the perspective mode is applied only after you view the sprite from different positions (move your camera around it). It is possible that as particle points are moving, they are rendered from different camera distances right after they are created, so we dont have time to notice how the perspective mode is applied a bit late.
Thats the only thing I can think of.

OK, since it seems like a driver bug, I moved along.

So how to make a sprite ,how to texture it properly and how to set the size properly?

From the above code I make a single sprite, then I use tree.copyTo(parent) to make corresponding sprites. It seems to work, but how would you measure the distance of the camera from the tree in the tree buffer? I would need to fit the tree model perfectly on the buffer texture. I could use the tree’s bounding box, but I dont know how exactly.

I then would need to scale the sprite to be the same size as the tree model. How? The size of a point sprite is set with setRenderModeThickness(), how does that relate with panda units used in 3d geometry?

I don’t understand what you mean by making “a single sprite”. Normally, the GeomPoint interface is used to make a cloud of hundreds or thousands of sprites. The whole point of the interface is to allow you to collect many points into a single Geom object so you can render them with just one call. If you are going to have one sprite in each different node, then you might as well use the Billboard interface, which is much easier to use but slower for lots of sprites because each object is its own node.

But maybe you’re planning on constructing a cloud of sprites one at a time, and then flattening them all together? That might work, though I’ve never tried it. But it would be a slow way to build it.

I don’t know what you mean about measuring the distance from the camera to the tree. You can use standard Panda scene-graph operations to measure distances between any two nodes; for instance camera.getDistance(tree). But this won’t help you much to fit a flat perfectly on top of an existing model. There’s a whole science for doing this precisely; you’d need to do involve the lens projection (because the field of view makes a difference).

Again, all this is much easier with the billboard interface, because there you’re just dealing with a model in model space. No camera space is involved (much).

As to setRenderModeThickness(), when you’re in perspective mode then this is the same thing as Panda3D units, up to the limit of size supported by your graphics card (most cards will only render particles up to a certain size and no larger).


If you want to do it like Ogre imposters I think they use an orthographic camera with width and height same as the bounds of the model, render to a texture buffer then apply that to a billboard with the same width and height as bounds of the model and add it to the LOD.

I have a tree that I just make a .png for outside of Panda, since the tree look pretty much the same from any direction, then I just apply it as a texture to a billboard or a simple cross quad model.

How exactly? Is it the “film size” you are talking about?

Now that i think about it it does sound pointless, I can just add vertices to the geom in the first place.

what do you mean? Billboards are just a task that repositions the node to face the camera in some way, right?
Here Im using sprites to be able to have 1 geom and I’m making a new texture for the sprites, which replaces the actual model with LODing.
If I used billboards I wouldnt be able to flatten them and I would still need to create the texture the same way.

That looks right, use setFilmSize(wid,hi) on an OrthographicLens object and set that as the lens of a camera. I guess the camera then points to a tree model and only renders that model to texture. Maybe saying textured card is better than billboard because you don’t need that rectangle to always rotate to face the camera, it only needs to be oriented once to face the camera since it is the more distant model of the LOD and get switched by the more detailed model as the camera gets closer.

Im not really sure … ics17.html