L B

The only thing I'll ever bother using for communities any more is Vanilla Forums. It's the most lightweight I found.

Confirming, tested in my C# implementation. I would also like this fixed somehow.

Bumpitybump?

Oh, right. Well in that case, let me rectify my statement: Your killer CPU versus my puny 2.3 GHz Dual-Core.

Not to mention your killer GPU, vs my puny 9600 GT.

Approved by LordHippo: Here are some comparison shots of with/without Crysis' SSAO (not his version (sadly)). I think it shows the difference quite well.

Get better soon! You can do it Can't wait.

Can I somehow disable culling or improve this specific case then?

I see, thanks for the reply. Can I somehow disable culling or improve its performance though?

There have been many discussions about culling performance. Notably: http://www.leadwerks.com/werkspace/topic/4449-showhide-heavy-trees/ http://www.leadwerks.com/werkspace/topic/3995-entity-cull-time-optimization/ http://www.leadwerks.com/werkspace/topic/3956-model-setviewrange-causes-crash/ Josh often says that he needs a scene file to test. Here is one, along with the 3D model "filler.gmf" used in it. http://localhostr.com/file/rg5ZGkP/Culling.sbx http://localhostr.com/file/xT1HJD0/Filler.gmf http://localhostr.com/file/QIcDJF8/FillerLOD1.gmf Here is a screenshot of the performance assessment: I want to stress the following points: The polygon count is 25k, which is nothing for Leadwerks. Draw time is 1ms. The world time is of 7ms, 5 of which are taken by entity cull time. This is enormous. I often get 6 or even 7ms taken by the cull time, out of the total 7ms. There seems to be 2376 entities drawn, whereas the square is 24x24=576 cubes. The other entities are the directional light. Perhaps the LOD counts as 2, but even then, it's not 2376. If you don't see performance drops yet, try multiplying that grid 4, 8, or 16 times. Then you'll notice cull time starts to rise in the 30-60ms. Another interesting point is that when you look down from the basic camera view, there seems to be a massive glitch in culling. Although no entities are in view (screenshot shows some only to indicate how I lowered the view, but you can lower further to show none), almost all the entities and polygons are still drawn. Also note that culling still takes the most of the render time. This seems to indicate frustrum culling is not only slow but bugged. This needs to be fixed, as it causes massive drops in performance for apparently no reason. Or, there needs to be a way for us to disable culling in that case. I'm interested in learning how.

Note that Newton supports obtaining joint force (applied?), but it doesn't seem to be implemented in Leadwerks. The documentation pages are off: they seem to have been copied from another function description, and not edited. But the functions and definitions are there: http://newtondynamic...llGetJointForce http://newtondynamic...ointGetRowForce http://newtondynamic...ewGetJointForce http://newtondynamic...erGetJointForce http://newtondynamic...geGetJointForce The ball joint seems to be properly documented. It should be really easy to implement.

I'd like to know a couple of things about joints: Can you (and if so how?) get the amount of stress (unit: Newtons) on a joint? Are stiff joints finally fixed? http://www.leadwerks...f-newton-joints The bug tracker is down. Without this, a lot of physics breakage simulation is hard. I could get the force on collision, I guess, but I can think of a case where I'd like the joint to break without any collision, out of the sheer mass suspended to it.

Thanks to all for your thorough answers. Considering I'm going with tiling textures and no animation (yet), I'll allow for intersection without trimming. I might change that later, but for now it works.

Does the demo now come with the headers? Dang, it's been a long time since I downloaded it.

While modeling trees, we generally use a basic technique: a cylinder-like (or cone-like, if you prefer) shape for each branch, and other cylinder/cones of sub-branches branching from it. (That's a lot of "branch", I'm hoping you follow). Now the usual way to handle trees (and meshes in general) is to have 1 unified "surface", and no intersecting parts. By this I mean that the sub-branches' cones won't dig into the main branch's cone, the modeler will trim off the excess parts inside the main branch, and make it end up nicely. To compensate for my poor explanation skills, here's a complex schema drawn with my even poorer MSPaint skills: Now, I'm wondering why said "trimming" is good. Does it impact performance positively? Does it remove visual rendering artifacts? Does it lower poly-count? Does it make smoother UV's? I actually think I can say it doesn't lower poly-count. Take the followind diagram. On the left, it shows the basic cylinder shape of the main-branch. The red convex polygon marks the intersection of the sub-branch. On the right, you can see the polygon rearrangement done on the main mesh in order to re-triangulate with a hole in the surface left by the trimming. As you can see, trimming actually highers the triangle count. Admittedly, I might not have done the most optimal triangulation for every plane, but I think I'm not far from it. Edit: There is actually 22 triangles if I optimize a little, but it's still more than twice the initial amount. The other argument I think is bogus is the fact that you can have follow-up, seamless UV's. From what I understood after plenty of Googling, artists tend to be creating separate UV maps for each branch, therefore (to my understanding) breaking the follow-up of the bark texture. Of course, they might be moving the maps around and playing with the settings to make the seam as subtle as possible, but it should theoretically still be there. Here's an image of what I mean. And the source: http://vanessav85.wo.../07/28/tree-uv/ You can also look at this YouTube video, in which the author uses the same technique, even if he has 1 uniform mesh: I haven't found another UV mapping technique for trees, so I'm assuming this is the norm. Now the remaining arguments (assuming I logically ruled out the first two, I'm hoping for input here), is that it removes visual artifacts and impacts performance is some other way. From basic renderings I've done in real time, I haven't seen any graphical artifact, but maybe someone will point a special case where it happens. And as to performance, I don't know what logically would. Perhaps some inner, useless texture lookups, but they'd be very minimal (probably less than 1% of the total area of the tree). So, why do you artists bother doing that? Quality standard? Any other reason?

HeroEngine uses collaborative map editing.

This video still is the only interesting use I've seen of tesselation, but I won't be going down that path. I'll try grouping ivy models in patches of ~2K-5K triangles, then instance these.

Tesselation is also the only way to calculate the velocity of an african swallow, as well as finding God and the true meaning of life.

I drool every time I see your Sponza screenshot...

Interesting part at 23 seconds: Vine is probably arranged in bunches, which seems to be enough precision for games. Perhaps this is the way to go.

The generation code is already provided. I'm just wondering how to make the display of the ivy possible in real-time. P. S. : I don't think you get benefits of instancing with bones. The main reason is that entities will geometrically differ. On static entities, LE sends the matrix information to the GPU instead of the poly information, which is why we get instancing benefits (I think). Again, if Josh could enlighten us...

I get around 45KT initially for a small vine. This might be -15KT for the roots, /2 for the 1poly/leaf, so ~15KT for a small vine. Definitely not viable if we want to have a diversity of vines.

I'm afraid what what we gain by decreasing the entity-count, we lose by not using the same 1-polygon mesh instanced multiple times (which Josh keeps saying is as fast as it gets). I'd be curious to know what Mr. thinks of this.

Oh, Iran. Didn't see that.

I think I'll use the usual Sponza model for testing (usually used in GI algorithms tests): The results could try reproducing this image: For the branch, I could use OpenGL to draw 3D lines instead of polygons - think it's a good idea?