Need Some Testers please!
Community Forums/Graphic Chat/Need Some Testers please!
| ||
| http://www.kcstudios.net/enginetests/treetest05.zip Best to run it in full screen mode rather then windowed, you will get better results.. the engine will output a 800x600 graph to the graphs folder after each run (and it will name it the most recent). Try different tree/leaf combos (IE 200 trees with 40 leaves, 50 trees with 150 leaves, etc). Let me know how it pans out for you. I havn't tried to peg the system with tree/leaf maxes yet because I am at work and dont want to sit here running it in fullscreen the whole night testing (besides, this is only a radeon 7000, which is nowhere compared to my gf4200 at home). Let me know how it goes please, thanks. Some Screenshots: Here is a shot of all 150 trees. The leaves are all moving in a seperate pattern (for the most part).  Screen2, this is a shot from inside the forest. As you can tell, i do need to add some better textures, and add more variation in to trunk formations and leave placement. Currently the engine just randomly places leaves on a tree (random coordinates within a set parameter around the tree).  And of course taking away the leaves for now, makes an interesting 'dead' forest (givin more varition in trunk formations:  |
| ||
| Ok, i did a few tests with varoius settings :o) I can't remember them all now :S But, i zipped up the graphs i got so you can have a look see for yourself. www.rosscrooks.pwp.blueyonder.co.uk/graphs.zip I think you would gain some more speed by splitting up the trees into clusters, so that there is isn't 10,000 leaves in the one surface, because they will get rendered, even if it's only one leave that's in view :o) Are you going to release this tree system, as it does look rather nifty :O) |
| ||
| Those are some nice results!!! Well, when I get to vary the trees a bit (add different types of trees), those will be on different surfaces (for organizational reasons). I have tested with multiple surfaces and found no performance hit. so thats a plus. Right now, I am not doing any LOD. I was thinking that leaves not in view (not in use) will get put behind the camera so that way they are A. Backfacing to the camera, and B. off scene. Also, anything 200 units+ away is pointless to animate since the user doesn't see much of the detail, so those are going to get a system similar to this just to control lod trees. ( http://www.blitzbasic.com/Community/posts.php?topic=46133 far bottom screenshot) Also, this system could use some more optimizations which at this point are futile to add (since I am just testing a certain part of this system, I wanted organization during the rough draft). Are you going to release this tree system, as it does look rather nifty :O) As soon as I get it to where it is showing good results, it is going into the code archives (that is if alienhead doesnt kill me :-) I doubt I will create a quick plug-n-play system for the general public though (such as blitztree), because then I would probably want to sell it (due to time/labor reasons). The technique seems rather sound though, I am probably going to try my hand at a particle system with this technique and see if it does better then the others out there (most of the particle engines I have tested from other blitzers have started to bog nearing 1000 particles, this wont be the case here). Thanks again for the test! |
| ||
| Can i ask what exactly your doing different? You explained it in another post, but i still don't quite get it. |
| ||
| Sure, although I am still unsure if it is really different or not.. Everyone is up about single surface stuff, but from what it seems, is they create their quads (hold them in a list no doubt) and simply rotate them to the camera whever the camera may be.. Basically mimicing a sprite with a bit more control over behavior and keeping everything in one mesh/surface. This technique is creating a mesh, parenting it to the camera, and creating my quads right infront of the camera (keeping the quads in a list of course). Assigning the id of that quad/list to a position on a tree. Each scan I tform the location on the tree to the quad mesh (giving me local coordinates in the mesh for where that location is on the tree globally). Then simply translate the quad to that position(locally) (no rotating involved because it was created facing the camera, so regardless of which way the camera is turned, it still faces the camera). Not having to rotate the quad to face the camer saves a HELLA load of cpu time. Like I said, not quite sure if this is different, its just different from how I understood others using single surface as opposed to sprites. Please correct me if I am wrong. |
| ||
| So, you are tforming the points to face the camera? I don't quite get what you mean by, you parenting the mesh to the camera. You'll still need to rotate the individual quads to face the camera. |
| ||
| You'll still need to rotate the individual quads to face the camera. Nope! Since the mesh was parented to the camera, and the quads were created facing the camera, regardless of which way you rotate the camera the mesh rotates with it, keeping the quads facing the camera. The TForm just takes the coordinates of one mesh to another (in my case, global coordinates to my local mesh). That way the only operation I need to do is move them to the tformed location (no rotation of the points is involved, and thus, no sin/cos manipulation). Function ModifyLeaf(ID,X#,Y#,Z#) Local L.LeafList,Sc# L = Object.LeafList(ID) TFormPoint X#,Y#,Z#,0,L\Mesh X# = TFormedX#() Y# = TFormedY#() Z# = TFormedZ#() Sc# = 2 VertexCoords(L\Surface,L\Vert[1],-Sc#+X#,Sc#+Y#,0+Z#) VertexCoords(L\Surface,L\Vert[2],Sc#+X#,Sc#+Y#,0+Z#) VertexCoords(L\Surface,L\Vert[3],Sc#+X#,-Sc#+Y#,0+Z#) VertexCoords(L\Surface,L\Vert[4],-Sc#+X#,-Sc#+Y#,0+Z#) End Function The X,Y,and Z passed in is where this leaf should be on the tree (the tree list holds this information of where on it all the leaves are relative to it's position). This merely TForms that point to its local coordinates, and I move it there keeping the original quad shape intact (the SC# and -SC#'s). No need to rotate the quad since it's already facing the camera, and it moves with the camera because it's parented to it (its mesh is). Still fuzzy? |
| ||
| Ok, so you have one quad parented to the camera. And are just taking it's co-ords and using them for every other quad? |
| ||
| no, making thousands of quads that are parented to the camera and merely moving their coordinates (translating). :-) |
| ||
| That sounds like a neat idea, I'll have to try it. Simply create quads such that they are facing the camera initially, make the camera the parent and then translating their positions according to the specific world coordinates for each 'item'. In fact it seems like a very easy way to implement a single surface particle system. |
| ||
| That's a very cool approach, I have an idea for a further optimization which I'll have a crack at once you post the source. |
| ||
| I didn't really get it in your other post, but now I really like the idea. I got a corrupt zip file though so I couldn't see it in action. |
| ||
| Well, I'll tell you what, I'll post the source if everyone (present company of course) agrees to keep any interesting modifications public. I plan on dropping the use of it with trees (initially anyhow) because I lack when it comes to doing good detail with trees. I was just going to use the system for particles and in-fact buy blitztree or something for the time being (time issues in development). unless of course that someone can create a tree system with it :-). I will add a few mor comments and bundle it up and post a zip today (probably in an hour or so). I am really interested in seeing what sort of optimizations you guys can make :-) |
| ||
| Alright, here is the source and media I used (tried to comment as best i could) http://www.kcstudios.net/enginetests/treetest_Source.zip Please give me a bit of credit if you modify the technique and use it. I don't want much, just a wee mention :-) it's always nice to know where your hard work goes. Also, if you have any thoughts on how to optimize this system, please let me know. I have thought of putting all unused leaves into a 'quad junkyard' and calling them out when they are needed (re-using memory) or creating new ones (if none exist in the junkyard), but that's in a much more advanced version of this demo. |
| ||
| Ah, gotcha now. Sounds very cool idea there man :D |
   |