Proposal: infinite detail through procedural generation

Threads related to Google Summer of Code
Post Reply
User avatar
pekar
Halfling
Posts: 92
Joined: Sun Mar 04, 2007 2:56 pm
Location: Belgium

Proposal: infinite detail through procedural generation

Post by pekar » Mon Mar 26, 2007 11:16 am

I want to apologize for posting this so late, but it seems like my time is up. A more in depth document about my motivation, and procedural generation in Ogre can be found at http://www.betaindustries.be/elvis/soc/proposal.html. It also has references and a short bio. The document is very concise, but I really have to make a deadline.

Code: Select all


Proposal

Abstract

Procedural generation is a concrete way of creating visual complexity without exponential increase in effort from the artist. I aim to facilitate the use and creation  of procedural content for users of Ogre. This would be done through alpha maps, which allow representation of 3d data as a simple image.

There are three components to the project:

A scriptable library for image generation. There would be a strong focus on the reuse of exsisting open source libraries for matrix operations/image manipulation.

A plug-in for Ogre to manage the visual complexity of the generated content.

A framework for experimentation with the scripts.
Goals/implementation

   1. Make a uniform interface for generating and manipulating images. This is the real generation part of the project. Design would be contract-based, to make the system extensible. The shared datastructure would probably be the images in memory, to allow flexibility of the system (mixing different libraries).
   2. Script the library.  The exact language of the scripting has to be discussed with the community. I was thinking in the lines of material script.
   3. Implement a procedural resource manager as a plug in. Minimal functionality:
          * Interpretation of the scripts
          * Detect the need of which level of detail is needed on particular content.
          * Provide the TextureManager with the generated textures
          * Provide the MaterialManager with updated material definitions
          * Add meshes (from a factory) to the scenemanager from a ditribution map.
   4. Make a demo, using PLSM for terrain,  textures for alpha splatting/terrain textures/skyplane, procedural distribution of Mesh Trees (if performance allows).
   5. Either refactor the demo so it can be used to experiment with the scripts (documentation through demo), or use an existing framework (I was thinking about CEGUI mesh viewer for materials, and GOOF for terrain).
   6. Make some small command line utilities to check the script, and generate complexity statistics. For debugging purposes, it should also be able to save intermediate images , or step through the whole procedure

Battle plan
April -June

    * Make a design document, as a platform for discussion
    * Discuss and research the actual scripting language.
    * Find out more about point 5, and discuss
    * Make a proof of concept of procedural terrain using PLSM
    * Go hunt for open source image manipulation libraries, and find out what's already been done in the community. Performance is an important factor.

week 1-2
Implement the library for image/alpha map manipulation.
Deliverable: procedural textures made through the interface, and applied to some common ogrehead.

week 3
Implement scripting.
Deliverable:: scriptable ogrehead.

week 4-8
Implement the resource manager. Scheduling would be done on a basis of priorities for performance reason. A cool idea would be to generate lower definition content. The real physical resource we're managing, of course, is CPU (and, to a lesser extent, memory).
Deliverable: ogrehead with dynamic generated detail.

week 9
Buffer. P

week 10
Make the demo. By then, I hope to know if this would be used as a framework for artists, or if I can plug in to an existing editor.
Deliverable: a distributable demo

week 11
Implement the command line utilities, and buffer if an existing editor can be used.
Deliverable: the utilities.
Else, more time for demo.

week 12
Documentation (Doxygen on everything and the demo, and a tutorial) , and deployment.
Deliverable: a document about the project in GSoC context, a list possible ways to extend the plug-in for the future.

Value of the project

The real lasting value of Ogre would be the Procedural Resource Manager, and the scriptable library. Once we have that, we have a codebase that can be reused for a long time (it scales well with technology), and can be expanded upon.These two would be implemented as an Ogre plug-in project. I'm not giving myself a lot of time for making the demo, but this is because I would already have a lot of demo code from testing the plug-in.  Content of the demo would either be programmer art, or some things my friends come up with (this would give me some immediate feedback on the usability of the scripts).
/EDIT I've submitted a slighly modified version of the proposal, because it's much too late to change it any meaningful way :evil:
0 x

Shadow007
Gremlin
Posts: 185
Joined: Sat May 07, 2005 3:27 pm

If I may ...

Post by Shadow007 » Mon Mar 26, 2007 2:09 pm

If I may, I'd like tyo point you to the following paper (regarding the distribution map) ... It may interest you :)

http://graphics.uni-konstanz.de/publika ... /webseite/

You may also find useful :
http://www.cs.kuleuven.ac.be/~graphics/ ... edCorners/
and http://www.cs.kuleuven.ac.be/~graphics/ ... nFunction/
0 x

User avatar
pekar
Halfling
Posts: 92
Joined: Sun Mar 04, 2007 2:56 pm
Location: Belgium

Post by pekar » Mon Mar 26, 2007 2:28 pm

Thanks,nice link. Sounds like an ideal solution to get the 'grid effect' out of the random distribution.

There is another way we could take this, if we use RTT:
http://mrl.nyu.edu/publications/painter ... raph98.pdf

Maybe I should chance my proposal to pointillist billboard clouds? (just kidding)

/EDIT I should have found this link much earlier: http://www.freewebs.com/ogremagic/index.htm. This is actually a good example of what the capabilities of library would be. The main difference is the emphasis on the paging of high detail, and the application of the alpha maps (I would focus more on materials and terrain, but render target post-processing should enabled by this). And it would be FOSS.

/EDIT2 This one too, of course.
http://www.ogre3d.org/phpBB2/viewtopic. ... sc&start=0
This could be very useful in generating streets, as in http://www.vision.ee.ethz.ch/~pmueller/ ... /Documents. Or they've already done what I propose to do (I'm looking into to it, but I'm an intern till 6 PM :(). My wishlist for image manipulation looks like this at the moment: noise, cellular algoritms and graphical primitives (like lines, but also polys to designate "reserved places"), and Wang Tiles. Any more pointers on FOSS implementations?
0 x

User avatar
Aladrin
Orc
Posts: 465
Joined: Fri Mar 10, 2006 10:22 pm

Post by Aladrin » Mon Mar 26, 2007 6:09 pm

From the CityEngine site: "Due to the now available computing power, I recently re-rendered some models I made in the early days."

Sounds to me like maybe his engine wasn't all that optimized, or that procedural content generation is still a bit too demanding on the processor.

Do you see your project as being something for creating the content in real time, at startup, or pre-generated?
0 x

User avatar
pekar
Halfling
Posts: 92
Joined: Sun Mar 04, 2007 2:56 pm
Location: Belgium

Post by pekar » Mon Mar 26, 2007 6:40 pm

Real time. Pre-generated is already possible in lot of existing tools, and wouldn't give this project any value for Ogre specifically, besides proof of concept.

The content that is created, is often content that has already been generated, but at a higher resolution. The main advantage of the resource manager would be the ability to swap lower definition LOD textures, with higher definition textures. As long as the high definition content is not created, the lower definition one would be used. Practical implemention would be to swap materials at runtime, which will be tricky.

A real plus of using procedural generation, is the fact that it is a pure memory and cpu bound process. Traditional ways of sharing content are based on disk access. It might be that loading pre-rendered is faster than procedural generation now, but cpu speed is gaining at a much faster rate than disc access (The future might be bright, but I know a couple of next gen consoles that still load from a silver platter).

Another major advantage is the scalability. To me, it seems Mr Mueller was able to generate much higher definition content without any mayor coding. This is because he can run the algorithm again (which seems to be deterministic), but ask much higher output of the procedural texturing. If he had modeled his cities in a traditional way, he would have to redo the whole model. Procedural generation requires a lot of work up front, but it pays off in the long run.

To really see the possibilities of pg, I would recommend

http://www.scene.org/file.php?file=/dem ... _party.zip

be sure to notice the filesize. Theoretically, the demo could be displayed @2560 x 1600, but I doubt anyone has the hardware to render it at an acceptable framerate... yet. Using traditional video, you would be stuck on the resolution the video is distributed.

...and one other thing (and then I'll quit, I promise). Because textures can be rendered in different 'chunks', this solution works very well in a multi-threaded environment.
0 x

User avatar
Aladrin
Orc
Posts: 465
Joined: Fri Mar 10, 2006 10:22 pm

Post by Aladrin » Mon Mar 26, 2007 10:10 pm

NSFW ;)

That's both 'Not Safe For Work' and 'Not Safe for Wine' lol Had to reboot to fix whatever problem it caused. Knocked me out of X and then x refused to start back up without a reboot.

.kkrieger and .werkkzeug1 are very very good examples of procedural content at it's finest. If that demo's textures showed right in wine before it crashed, .kkrieger has it beat hands-down.
0 x

Post Reply