Page 1 of 1

Computer Graphics from Chaos

Posted: Fri Dec 15, 2017 10:43 am UTC
by jewish_scientist
Its after 5:30 AM, so I am too tired to explain. Really short version, why does this not take up a huge amount of processing power? Thanks and sorry for being so brief.

Re: Computer Graphics from Chaos

Posted: Fri Dec 15, 2017 12:11 pm UTC
by Zamfir
I am not quite sure what you mean, but if you mean rendering every leaf in a forest, then sure, that takes time. But if you really want to render every leaf, then on-the-fly randomized generation might well be faster than loading them from a pre-generated file. I/O takes time as well.

In practice, there's a company called speedtree that sells you 3d models of reasonably looking foliage, with a toolkit to modify them, and a built-in engine that replaces trees with simpler models when they are far away. Lots of games rely on such libraries. And they don't model every leaf in the forest, not by a long shot - there's all kinds of tricks with textures and shading that make the foliage look more complicated and varied than it is under the hood.

Re: Computer Graphics from Chaos

Posted: Fri Dec 15, 2017 12:16 pm UTC
by Tub
jewish_scientist wrote:Really short version, why does this not take up a huge amount of processing power?

You don't use these algorithms to render each frame, you use them to generate models and textures, and then you use those models and textures for rendering as usual.

For complex algorithms, you can pre-calculate everything and store the finished models and textures on disk. You don't need an infinite amount of random trees anyway, just having a few dozen variations is probably enough to make a sufficiently realistic forest. But a few dozen trees are cheaper to generate by an algorithm than having an artist burn out while doing the same task 50 times. There's also plenty of shared resources between different trees, like bark or leaf textures, so the memory overhead isn't as huge as you'd think.

Or you can do it while loading the map. Depending on the speed of the algorithm and the speed of your hard drive, dynamically generating these things can actually be faster than loading a pre-generated model from disk.

Re: Computer Graphics from Chaos

Posted: Fri Dec 15, 2017 2:14 pm UTC
by p1t1o
Arent some common data-compression techniques fractal based?

Re: Computer Graphics from Chaos

Posted: Fri Dec 15, 2017 7:37 pm UTC
by Tub
p1t1o wrote:Arent some common data-compression techniques fractal based?

Most of the data you're handling is not the result of a simple fractal. It's not a suitable approach for general purpose compression, and I'm not aware of any common software that used it.

There's been research though:

Re: Computer Graphics from Chaos

Posted: Mon Dec 18, 2017 1:37 pm UTC
by jewish_scientist
The way it is described, this method decreases memory allocation (2 triangles + 1 equation = a few bits) and increases processing power (equation needs to be run on 2 triangles ~1,000 times or so for each fern*). It was my understanding that the more important limit on modern computers was processing power. For example, people bragging about their cutting edge supercomputers do so about processing power, not memory. Then again, maybe the reason memory is not so big an issue is because of trade offs like this.

*To get the detail he did, you would imagine you would need to do ~10,000 iterations. The reason I put this estimation is that I bet that using textures that include transparent sections could decrease this requirement 10 fold.

Re: Computer Graphics from Chaos

Posted: Mon Dec 18, 2017 3:32 pm UTC
by Soupspoon
Ten thousand cycles to build one 'archetype fern' (x5-10, for variations beyond various transforms, as you ads other clumps?), and another 10k cycles to maybe build an archetype willow and another 10k to build an archetype clump of moss and/or lichen (very detailed, in case you go in that close) on a prominant eratic/mystic stone that was itself procedurally generated in the middle of a procedurally-generated glade of various other procedurally-generated trees within a procedurally-generated valley in a set of procedurally-generated foothills betwixt procedurally-generated mountains and procedurally-generated shoreline (upon which laps a whole slew of procedurally-generated waves, all in one go) is not so difficult to do, compared with all the above being stored, to an arbitrary LOD, as pure data, sufficient to withstand scrutiny at any level of zoom from planetary to microscopic, with or without an assumption that this one spot would always be the focus of the scene...

There's optimisations that you might want to use in real-time/responsive rendering, but you can farm the processing out into frames and batches if you're trying to make a movie out of the result, knowing that as you pan-and-scan the scene, or zoom in or out, you aren't going to suffer from trees suddenly popping into existence and back out again, or vastly changing shape if they stay, because the 'randomiser' didn't come out the same for each iteration of discovery.

But it depends what you want the result to be. For what purpose.