Right.
So anyway, it worked.
If anyone else is interested in how to convert Ogre mesh to blend->egg:
In Ogre, .mesh is like .bam and .xml is like .egg.
The above script says it can import both, but you need OgreCommandLineTools installed and it should call OgreXmlConverter.exe during import, but it didnt for me, so you should navigate to the OgreCommandLineTools folder (‘C:\OgreCommandLineTools’ for me) and drag-drop the mesh files to that exe and it should create an xml in the mesh’s folder. The xml can be imported then, but textures arent imported, you can guess the texture name by the material name and load it manually. Set MapInput to UV and enable ‘Alpha’ in MapTo. Optionally enable Ztransp in “Links and pipeline” and set “A” (Alpha) to zero for material color. Save blend and export to egg:
(pview)
Any ideas how to include the whole PIL library in the sourcecode so everyone won’t have to install it separately?
BTW rdb, you suggested something like blue channel for the type of the tree, green channel for the size of the tree and alpha for colour tint or position randomisation, well um… did you simply forget the actual x,y position of the tree? because by my knowledge of image formats theres nothing left. Btw, both heading, pitch and roll in an integer?
OK, here: freefilehosting.net/forest
Now about the loding, flattening… how to do it? Flatten operations are irreversable.
btw, i suffer framerate drop when there are ‘too many’ trees on screen, that is caused by transparency. i dony understand why panda should slow things down with few trees with aplha texture when the Ogre samplr has like hundreds on screen
I haven’t had time yet to look in the Ogre paged geo code. I know they use your method to “splat” grass, bushes, trees, using texture map channels.
I experienced slow performance with OpenInventor many years ago when making many objects completely transparent ( expecting things to be faster ). What happened was that OpenInventor code was still calculating on every pixel even when it was completely transparent. I told our vendor about it and our next update had a fix for that. Not sure if this is a similar situation in Panda…
I mean the branch textures have alpha channel. Ive actually made a thread about this saying I get very bad performance with trees and grasses for that reason and even posted some PStats screens. We concluded that I should cut the amount of branch/grass geometry. But now i see that its not just my own models. The same trees are of hundreds in the Ogre screenshots. Im only familiar of MAlpha, MDual and MBinary mode and they all give me big framerate drops. Ive actually tested some real games that have far more trees and grass geometry with alpha texture and they dont seem to slow things down.
I sure hope this isnt a Panda bug or issue, I doubth that though, someone would surely notice it by now. So theres probably something I dont know, but noone told me anything.
Btw, i dont think it looks great right now. its only around 100 trees, not thousands like in the Ogre demo.
It’s not the geometry, it’s most likely the amount of batches sent to the GPU. This is a common mistake. Try to reduce it by clearing out model nodes, grouping groups of trees under the same model node, and then flattening the whole.
You can verify that this is indeed the problem by calling .analyze() on the node that contains your trees.
number of trees: 94
189 total nodes (including 0 instances); 0 LODNodes.
0 transforms; 0% of nodes have some render attribute.
188 Geoms, with 94 GeomVertexDatas and 1 GeomVertexFormats, appear on 94 GeomNod
es.
67586 vertices, 67586 normals, 0 colors, 67586 texture coordinates.
GeomVertexData arrays occupy 3697K memory.
GeomPrimitive arrays occupy 338K memory.
186 GeomPrimitive arrays are redundant, wasting 335K.
57622 triangles:
0 of these are on 0 tristrips.
57622 of these are independent triangles.
2 textures, estimated minimum 1792K texture memory required.
I guess Im not using flattenStrong() properly.
Still though, I dont think thats the problem. Its a massive framerate drop when looking at the tress. Even 1 is enough. Thats something I experince even if I have my tree/grass as a single mesh in Blender before exporting. It happens only with alpha textures.
That’s 188 geoms (two per tree, I assume because the leaves and bark have different textures so they can’t be merged). That could be the culprit. It’s not that much, but depending on your GPU, it can still significantly contribute.
Of course the drop only occurs when looking at the trees. If you don’t look at the trees, Panda will cull away the trees and they won’t be sent to the GPU.
Maybe you’re not using flattenStrong right indeed. (Perhaps you are not properly removing the ModelRoot at the top of the tree model?)
The approach you should take is: clear the model nodes at the tree model (using clearModelNodes), then put every group of a few trees under a node (until you end up with perhaps two dozen groups), and then flatten everything below every group node.
This way, you will get the advantage of flattening while maintaining most of the advantage of culling.
Could you let us know which GPU and GPU driver you’re using?
I doubt this is a bug in Panda.
PS. As for geometry complexity: it’s quite unlikely that that is the bottleneck here. You only have 58000 triangles, which is toast for an average GPU.
Yeah i dont. Ill fix that now. But that wont be the solution for this issue.
thats not what i meant by too much geometry. Like drwr said in the other thread:
Well now Im not even using the geometry I made and the exact same models are used in Ogre.
Like I said, even a single model slows things down dramatically. heres the tree model loaded in pview:
See what I mean?
Ive tested these on few hardware, most of them being notebooks. But they are relatively new hardware, i5’s, i7’s, 1-2gb graphics memory. I dont think notebooks lack something used by desktop pcs for handling transparency. And again, Ive tested some real games on them and I don’t notice any slowdowns for grass/trees, etc
it is online. Its in the archive I posted here: freefilehosting.net/forest
The trees are in the folder ‘media/trees2’. f the download is too big I can upload a separate egg.
I still have no idea of which hardware you are using. Perhaps you’re using software rendering?
All of the trees, in full view with lighting and shader generation enabled, have over 1000 FPS on my laptop which is several years old already. It’s an NVIDIA GeForce 8600M, for the record.
Wow, those are much more modern GPUs than mine. I don’t know why they would be displaying the trees at such low FPS. I can’t debug with pstats because I don’t have those GPUs.
Tested here at 8600GT. (C2D, P3D 1.71)
Very close at farn1.mesh.xml.egg: 350fps
Very close at farn2.mesh.xml: 200fps
The others gave me better results very close or at full view, from 650 to 2500fps.
I think everything is normal until the camera gets very close to the transparent parts. Dunno if that’s normal, and seems like the same problem he had.
Not very close, unless for you the camera is very close to the tree in the screenshot i posted.
And it seems as you get more trees on screen, the required distance for noticing framerate drop decreases.
That seems like the cause, but its not ‘very’ close at all. I would still like to know why getting that close to the transparent parts affects the framerate, I havent noticed that kind of behaviour in any game (and I actually ran the games just to try that out).
