Grass in games are usually flat billboards with two-sided sexturing. In order to achieve the desired effect I want, I would have to have a lot of these little alpha holding grass billboards.
Would I be fine if I use the “rigid body combiner”, which is mention in the Manual, to combine all my grass instance into one Node, supposely?
Well, reading the RigidBodyCombiner manual page
shows this text:
Which makes me think that using the RigidBodyCombiner for this would… only work if grass was static and never rotated towards the camera.
However I think you might be able to use manual rotation (eg setH() instead of billboard effect) to create your own billboard effect with the RigidBodyCombiner, the performance trade off of using this method I’m unaware of however.
I suppose you’d have to try both and compare their performance using pstats
Hope this helps,
~powerpup118
you could also try using the cross quad type of grass, where you have two to four rectangles crossing each other with the same grass texture. You can collect them in say groups of 5 or so depending on how far apart they are and flatten strong the parent node of each group of cross quads, this will help to keep the number of geoms lower, and will not need the processing to keep polys facing the camera.
The RigidBodyCombiner works for moving and rotating nodes, but it’s overkill for when you simply have static quads that don’t move, in which case you can use flattening. If you have grass, it is probably enough to have three planes intersecting so that it is visible from all angles.
Grass isn’t usually implemented as billboards, as this would make the grass rotate when the camera moves, which doesn’t look very good.
But the best option would probably to make sure the quads are in a limited amount of nodes in the first place - one way to do that would be to generate them in code.
By markjacksonguy at 2012-02-16
The sun is going down in the scene, so it’s kind of dark. Anyway…
I was thinking maybe all those test building instances should be grouped in some way. Would sending all those different building instances as a single not cause performance drop?
How can they be grouped if “rigid body combiner” is for moving/rotating objects only?
What I’m doing in the code is not calling flattenStrong until a building has been place. Why? Because the player will be able to move and rotate each building before placement. Once placement happens, I then call flattenStrong on the building because it is done moving.
The only other thing the player can do at this point is destroy the building (which I haven’t written code for yet).
These buildings will go through graphic change as they build up from one level to the other, but I will simply detach the flattened geometry and re-attach another flattened one to the structure’s PandaNode.
I read somewhere that P3D wouldn’t be able to handle a lot of smaller pieces of geometry and that is what I will run into with all the building instances.
If you put all the buildings in one geom then even if just one building is in view then all other buildings will be send to the gpu.
If you have 1000 objects then that’s still better then to send then one at a time. Lets say each has 500 polys and only one object is seen by the camera - the gpu still has to process 499 500 extra polys that are not even visible. Quite a waste.
How about attaching a placed object to a nearest already placed object (within a given radius) and then flatten then? You’d end up with less nodes/geoms and they’d be in groups perfect for frustrum culling.
The tricky part is finding the nearest object (collision spheres spring to my mind).