L B

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?

I'm going to try generating ivy in Leadwerks, in real-time. The beauty of IV comes from its individual leaves, so I'm asking for some optimisation tips. Here is a beautiful ivy renderer: http://graphics.uni-.../ivy_generator/ Obviously this is not RT. I'm thinking I can harvest the power of Leadwerks instancing to achieve the result. 1 triangle per leaf is possible (with the right UV setup). The problem might be the massive amount of entities. How do you suggest I do that? Of course I can use billboards in the distance, but again, the entity count will be high. Perhaps I should avoid entites, but I don't know how. I don't need tips on the actual generation algorithms, I'm getting pretty good at this. Just on the performance aspect. EDIT: Actually, it's open-source, so I might just port it to Leadwerks. It's even allowed for commercial projects.

Great. But let me complain about icons: Use one consistent set! The FatCow one I linked you has a Folder icon, and a Lightbulb icon. If you need other specific ones (e.g. 3D cube), ask an artist for help. I know a good hobbyist for this task, he probably won't charge a lot (<$100 for all your custom FatCow-like icon needs). I know he can work well with that set by experience. PM me if you want the details.

Of course, if your employer requested the shader for a product, and stipulates in a signed contract and/or agreement with you that all works produced within X period, including shaders, are the company's intellectual property, then don't complain; it's normal that you can't release it. But that's rarely if ever the case for junior programming jobs. And considering LordHippo is 21, this one job probably is. Employers tend to be very loose on contracts, if even there is a contract. I developed, for example, a whole CMS for my employer, which I could legally resell. All I got from my employer was an informal email telling me not to do that, almost with a pretty please. Truth is, all that matters is legality. Employers, especially greedy and bad ones, tend to use intimidation and exploit the ignorance of junior employees in order to abuse their intellectual property or other work rights. But it's not legal, therefore it doesn't stand.

"Now" being the keyword. This is developer abuse.

Haha. Simple, hilarious and effective. Moreover, upload it to a reliable code directory like Google Code, so that the upload date can be trusted and grant you prior copyrighting. In any case, any original code you write is copyrighted to you, notice or not, unless you specify otherwise in a written manner (e. g. contract).

Unless he can legally bind your code to his company by a contract, he may not stop you from publishing your code. Now, the legal part of this will hang in a couple of factors, all depending on said contract (if it exists), including whether you coded this on your work hours (assuming you're not doing freelance task-oriented work but workplace hours), whether this shader was requested for the product, etc. If he threatens to fire you or whatnot, without legal backup, you can contact work protection agencies in your area who will gladly support you in fighting back. Chances are that if he seems to feel threatened, he simply realized that you did a great shader and tries to take it from you, without that being in his right.

Mmm... Leadwerks 3 + PolyVox + partial terrain models (as in CE2). Yummy future ahead, perhaps...

I believe both systems are used: precaching nearby chunks, and using octree for outer cubes and drawing only outer faces. As to using octree to only display outer cubes, I think we'd have to play with more algorithms than are built-in Leadwerks. Besides, considering how Minecraft works, say you break an outer block, you want to load the one behind, and thus perhaps a preload of ~3 cube depth from the surface should be used. What do you think? As to drawing only outer faces, I can't say really. I'm far from knowing anything worthwhile in 3D render programming, but doesn't basic culling prevent from the GPU computing invisible (hidden by depth) faces? If it is so, there's no more algorithm to be added.

Minecraft breaks in (XYZ) 32x128x32 chunks. 64 above surface and 64 below. I suspect the chunk you are in is "active", and probably even the 8 surrounding ones. That means 32x128x32x9=1 179 648 entities, if they're not air-filled (which IMO takes roughly 40% in Minecraft), so let's say about 700 000 cubes. 700K active cubes? IDK how to handle that. They're not fusioned because you're close from them, so modification would be costly. How do you think we could handle that? First, we could have 16x16x16 chunks, and we'd have 3x3x3 of them loaded at once (cubic area around us), so 16x16x16x3x3x3=110 592 active cubes. Times ~60% (assuming we have some 40% air, usually), 66 355 cubes. Say we have about 70K cubes to handle. Better than 700. The price for dropping to that was that we have to switch between prerendered versions and active versions more often as the player moves in the world. That might be costly, but might not as well. We'd have to test. Theoretically, if the loading time of up to 15 chunks (~40K cubes) (assuming you move diagonally on the X, Y, and Z axis at once) is smaller than the time taken to traverse a chunk, there is no problem, because surrounding chunks can be loaded faster than the player accesses them (hence the whole advantage of having surrounding chunks preloaded). Loading 15 chunks is the most extreme case. All other cases, when moving along the X, Y or Z axis of 1 chunk would require the load of 9 chunks (~25K cubes). Assuming 1 cube is 1 meter (as Minecraft handles it), and the player jogs at about ~10km/h, traversing a chunk of 16 meters (the minimum time, in a straight line), would take 5.75 seconds (let's say 6). This means that loading 25K cubes has to happen under 6 seconds. I think it's feasible. On another thread, it could happen seamlessly. If you walk in a diagonal, in which case we reach the 15 chunks case, you have to do a distance of about 28 meters, in a straight line. This would take about 10 seconds. This means we have to load 40K cubes in 10 seconds, again, I think it's possible on another thread. This means you have to load approximately 4K cubes per second. If Leadwerks 2 can do that, we're in business. in terms of polygons, this is 48K polygons per second, but I don't think this ratio is relevant. Polygons per second, lol. Remember though that cubes might sometimes be rounded (>12 polys). And can have some kind of props or other things.

For many implementations I would want it on bright surfaces as well. If ever this is released, I'd be thrilled to know how to make it work regardless of the lighting amount. I'll ask again though, will it be released? It's truly incredible.

He already gave one with diffuse off, I wanna see it on.

Can you do a comparison shot of that model with LE2's default SSDO vs. your SSAO? Looks great, by the way.