Natural Detail Engine

Posted by Font on Dec. 5, 2011, 7:32 p.m.

So I'm completely new to this community, but my roommate (Flashback) suggested I join and show off what I'm working on.

Ever since I saw Unlimited Detail (now Euclideon) on YouTube, I have been enthralled by the concept of pretty graphics in massive quantity and detail. Though I tried, I could never quite understand how Unlimited Detail worked. During hiking trip in later half of this summer I reached a lookout on a mountain and saw the millions of trees below and thought "Wow… I want to render that scene".

That's a lot of trees…

Since I failed to understand how Unlimited Detail worked, I decided to come up with the next best thing. My idea was to take highly detailed models, such as trees and shrubs and render them onto sprites before displaying them on screen. Not very revolutionary or original I know, but this way the engine can render a few trees a frame and leave the rest of the trees to recycle their old images. If the trees are far enough away, the user won't be able to tell anyway (the closest trees are swapped for real polygon models instead of sprites). I deemed the project Natural Detail and started turning my idea into reality in late August. It's been off and on ever since.

I've ran into a variety of problems since I started. I'm relatively new to hardware accelerated graphics and didn't know how difficult it would be to manage hardware memory. You see, every tree had to be associated with an image, and these images had to be stored somewhere. To solve this I made a massive texture for every entity type and gridded it up so that it could hold 64 images or so. There's a bit of a problem, cause I want to render millions of trees, and there's less than a hundred spots for images. The solution was that every entity of that type had to search through the grid and either render themselves to a place on the texture, or find another image that was most similar to them and associate itself with that one. I also wanted to fade the images together, but I had to double my memory usage in order to do that, so I still haven't figured that out quite yet. I also got anti-aliasing working, but since my sprites aren't z-ordered, it makes the sprites look super weird when it's on.

The trees must choose!

So far, all this effort and discovery has led me to my latest iteration, which showcases grass, flowers and trees, swaying in the breeze.

I was really excited when I got the grass and tree sway working. It really made the scene come alive, even though there's still some popping and jittering when the scene shifts around (working on it). I'm pretty satisfied with the result, and I'm hoping to implement my engine in a multiplayer shooter I'm concocting in my head.

Anyways, I hope someone enjoys this sort of stuff. I'm pretty new to this stuff, so if anybody has any suggestions or revelations (or you demand a tech demo), feel free to get a hold of me! ^_^

Comments

JID 12 years, 11 months ago

For those that keep asking,

Quote: his video
Using c++, sdl, opengl, arbaro (for tree model generation)

Font 12 years, 11 months ago

Wow. Cool…. Yah, it's c++ and stuff … yeah fading models is harder than it looks, but I'm trying to find a solution… thanks, I feel welcome… naw, my roomies and I, were a big computing science family, flashback only bans me on occasion. Thanks guys.

LAR Games 12 years, 11 months ago

Amazing. It'd be awesome if I could try it myself.

I wanna walk around the pretty forest. :D

Taizen Chisou 12 years, 11 months ago

That looks pretty sweet.

Welcome to 64.

Moikle 12 years, 11 months ago

wow.

S3xySeele 12 years, 11 months ago

I too am very enthralled by the Unlimited Detail engine. Never thought to try my own hand at something similar, though.

Your Natural Detail engine is pretty fascinating. Not exactly sure how rendering the trees to a sprite and then the sprite to the screen would be faster than just rendering the tree to the screen though… unless it's to keep from having to re-render it every frame.

…In which case, your engine should only not re-render the frame when the camera is staying still or moving left/right, up/down, or forward/backwards, since these only result in scaling and translation. You should definitely re-render when the camera rotates though, since it becomes obvious that they're sprites at that point (unless they're close enough to become 3D models) and you might as well just be using sprites instead of this fancy 3D-to-sprite engine. …Or, on second thought, maybe it'd look better to only not re-render when the camera isn't moving, period.

flashback 12 years, 11 months ago

It's much less expensive to render a tree to a flat sprite, then a whole bunch of sprites in a scene, rather than adding millions upon millions of polygons to the scene (or at least so I understand it).

S3xySeele 12 years, 11 months ago

Yes, I get that concept. But if you're gonna be rendering a tree to a flat sprite and then re-using that sprite all over the place, it'll look about the same as if you were just using a pre-made tree sprite.

The only difference really is that you can apply some basic lighting to the tree to make it better blend into the scene… which might be somewhat useful for a game where the lighting conditions of the scene are dynamic, perhaps due to a day/night or weather cycle.

Edit: Also, it can dynamically move/sway… but, since it's being used multiple times, this could result in it looking strange because the trees are swaying at the exact same time in the exact same way.

Font 12 years, 11 months ago

You can imagine this process as dynamically billboarding. This way you don't have to spend extra time making sprites by hand. The engine only rerenders trees when the tree model has rotated a relatively significant amount. I understand this is far from the perfect solution. I appreciate the input.

Rez 12 years, 11 months ago

One step closer to playing God!

Awesome stuff, I hope to see more.