Talk:Procedural generation

From Wikipedia, the free encyclopedia

This needs to be changed. It is Spore specific right now and copys directly from the Spore entry making it redundant since thats probably the only place that links here.

It's a very interesting concept that will become more and more games will use. I'm removing the cleanup tag. Jacoplane 19:19, 31 July 2005 (UTC)

The article may be brief, but its spore specificness is only due to a lack of examples. It deserves an article of its own, however, as it is an entirely different concept to procedural textures.

There's also the article on Procedural programming.


Personally, I don't see the relationship between procedural generation/texturing and procedural programming. Sure, you can use a "procedural-programming language" to do procedural texturing and such, but it's just like saying you can write programs using C/C++. By the way, that article is not really useful in my opinion.

Anyway, the point is that the relationship is too weak for me. It's like saying that, if you don't understand the working of C/C++ you should check out imperative languages. Sure it helps but the concept is on two totally different dimensions. It's more likely the average user will end up messing various concepts.

The two are getting linked just because they share the word "procedural" but as I see it, the meanings of that word is different in the two contexts. This is very unfortunate since I hardly believe any useful procedural generation algo (SpeedTree comes to mind) can be written using procedural programming methods.MaxDZ8 talk 11:29, 6 February 2006 (UTC)

I think you are correct. The procedural programming page should not like to procedural generation in the See Also section. The two are unrelated in any meaningful way. Jessmartin 06:00, 17 February 2006 (UTC)


Revert pending for User:Ashley Y version. The user linked this page with functional programming. I am going to revert it for reasons similar to above. This time, it's claimed procedural generation to be a subset of functional programming. I consider the linkage to be way too weak. If procedural programming has been removed, by sure means this also should be. To re-state a concept above: no doubt you can do procedural generation with this paradigm but it's way too general. There are also a lot of real-world scenarios in which the whole thing just does not fit. Last but not least, the reading of the linked resource does not seem to be very useful and the category added is about heavy mathematical wizardry. There's nothing wrong in that but this makes me think this would be out of place. 83.176.85.211 08:58, 13 March 2006 (UTC)


Contents

[edit] Merge comments

I believe this shall survive the merge with procedural synthesis. Although as far as I know "synthesis" is the correct term, it's more likely average Joe will like "generation" much more. I'll work on a offline merge in the next few days and propose the results soon. MaxDZ8 20:52, 28 November 2005 (UTC)

I've merged the two pages. I believe this shall now be merged with procedural texture, mainly because the other is very short and I believe it's good to have few big articles than jump here and there. Texturing is just an application so it's also another good reason to merge it. MaxDZ8 18:43, 29 December 2005 (UTC)

I've noticed the proposed merge with procedural texture has been removed. I'll take this as proof some people wants to keep the two pages separated. I believe I'll spend some time on the other page in the next few weeks. MaxDZ8 09:04, 13 January 2006 (UTC)

[edit] Other Procedural Generation methods and related topics

There are some other procedural methods which should/could be mentioned in this article:

  • L-System - Procedural method for generating trees. This should particularly be mentioned in the speculative paragraph about trees.
  • Fractal landscape - Procedural method using fractals for generating terrain.

Quite a few other things relate to these methods as well. Procedural textures and Perlin noise are just a few examples. This article could ideally be restructured to include a more general overview of the variety of techniques used in this area as well as some applications.Jessmartin 06:08, 17 February 2006 (UTC)


I don't have much knowledge of LSystems and I only know basic facts about fractal landscape generation but the actual definition of this latter thing seems to be quite different from what I know. Linking to procedural texturing has been considered as you can see above, but then I moved on editing another page with higher priority (this is "quite nice" actually) and forgot completely to blend it in the text. Same fate happened to Perlin noise references.

It takes a little bit of extra effort than adding a few links or embedding the references in the text nicely. I discussed on the help desk some time ago the need to supply code pieces to demostrate some "almost real" examples but we couldn't find an useful agreement on the language or technologies to be used. This annoyed me pretty much and made me focus on another article. Now that you're providing extra knowledge, I am confident we could finally raise the bar on this topic to useful levels.

There's also the problem that I kept a lot of content from previous revisions (see the blue box?) but I wasn't able to verify it and I personally dislike the whole chapter. What do you think about this issue? MaxDZ8 talk 22:27, 3 March 2006 (UTC)

[edit] Example of procedural generation in DOOM

In DOOM (the 1993 version), iD software had a feature called "auto-pitch" I believe, which adjusted the pitch of sounds randomly when the sound was played. Forexample so that gunshots would sound different, or when selecting stuff in the menu.


I'm not sure I remember this one but I'd rather look at it as a sound processing effect and as far as I remember the sounds were taken from pre-made files so I don't see the connection with procedural generation. Thank you anyway for pointing this out here. MaxDZ8 talk 16:14, 6 March 2006 (UTC)

[edit] This thing...

Procedural generation as an application of functional programming

Procedurally generated content such as textures and landscapes may exhibit variation, but the generation of a particular item or landscape must be identical from frame to frame. Accordingly, the functions used must be referentially transparent, always returning the same result for the same point, so that they may be called in any order and their results freely cached as necessary. This is similar to lazy evaluation in functional programming languages.

I understand this is page actually unverified but I still think something should be put here with salt. Regarding the above statements, I would say that:

  • This is way too short to be a chapter by itself.
  • The statements introduce external concepts (functional programming, lazy evaluation, referentially transparent), this would be good but I personally believe those are way too far from the topic.
  • Some of those properties are adviseable but not always required.

Could you please point out the goal of that? MaxDZ8 talk 10:49, 21 March 2006 (UTC)

Procedural generation happens to be an application of functional programming, and really ought to be called "functional generation". The problem is that the people who write procedural generation code don't seem to be very familiar with functional programming, so the connection isn't obvious to them. They may create generation functions and be aware that the functions will usually have to have a certain kind of property, but may not be aware that computer scientists refer to that property as "referential transparency", and so on. —Ashley Y 09:17, 10 July 2006 (UTC)

Your point is taken. I admit that having being self-formed, I lack the academic ... things (I have however used functional languages for almost three years). Yet, I still think this degree of abstraction to be far from correct (as I disagree with most academic stuff I know about). Why? Because there's nothing like "functions" inside a computer. It happens that a series of binary tokens works so similar to numbers and operations some math guru thought it would be nice to estabilish a link between math and physical computers. As now, I think the model envisioned to be actually more involved by the facts themself, thus defeating the need for a model.
After having read your rationale, I am convinced you know the issue. I won't revert anymore your additions, but I still disagree with this. Do as you feel better, however I still think that working with abstraction levels, hypotesis and audience, in computer science is possible to say everithing and the opposite of it, yet hit the truth.
MaxDZ8 talk 08:13, 11 July 2006 (UTC)

[edit] Landscape/Terrain Generation

Would an article detailing terrain generation fit as a stand alone article on Wikipedia? Since there's a lot of terms for it (pretty much any combination of "procedural"/"generation"/"synthesis"/"terrain"/"landscape"), what would be an appropriate title? Indeed, there is already an article on procedural textures, although it does seriously need more content. In any case, there are already several articles concerning terrain generation algorithms and a "parent" article is sorely needed. I'm pretty sure I'd be able to fit in a lot of content. Nezbie 05:10, 2 May 2006 (UTC)

I'm not aware of the other articles... could you point me to them? To reply you I would like to take a look. MaxDZ8 talk 15:53, 2 May 2006 (UTC)

I wonder if there are any orphaned articles on the subject. In any case, some relevant articles include: algorithms (Fractal landscape, Diamond-square algorithm) and software (MojoWorld, Terragen). The applications and widespread use of terrain generation alone should make the topic worthy of a full-fledged article, including elaboration of some of the most used techniques (including subdivision algorithms, frequency synthesis, faulting, noise, etc...). Nezbie 18:39, 2 May 2006 (UTC)

I agree that this topic really needs its own page. Covering this here is definetly brain-damaged, considering the amount of detail needed. There will probably be some merge/redirect to do... fractal landscapes are procedurally generated landscapes for example. Maybe the topic needs even more than a page (algorithms and software perhaps).
It looks a dauting task. Good luck!
MaxDZ8 talk 17:33, 3 May 2006 (UTC)

[edit] Sound

This sentance didn't make sense to me, so I removed it: "it has been employed in many songs (for example The Cure's songs largely employ synthesizers while techno music is often largely synthesized)". Creating electronic sounds seems a far stretch from procedural generation. (Feel free to correct me, of course.) Tlogmer ( talk / contributions ) 16:22, 6 May 2006 (UTC)


To tell the truth, I has been told about this by a friend and I really cannot prove it so I agree with this.
As for the citation needed, what actually needs clarifications?

  1. Synthesis VS generation?
  2. Electricity + creativity = Synthetized sound?
  3.  ?

MaxDZ8 talk 10:37, 7 May 2006 (UTC)


I am not an expert in procedural generation/synthesis; to my understand is that procedural systhesis, in computer graphics, is when you use some sort of algorithm to generate graphical content in real time rather than taking a "sample" of texture or use a pre-computed information. If my understanding is correct; I would like to make a clarification as how the procedural synthesis in graphics can be compare to sounds. without goin' into digital vs. anglog sound synthesis details, typically, there are two common way to create sounds: synthesis and sampling. synthesis is when you "generate" a waveform via oscillator; then pass it through bunch of filter to produce a desired sound (waveform). you can say that the procedure is done in real time as you can modify your originating waveform in your oscillator directly; the changes made is immediately effects your output sound. sound producer use various tools to shape their output sound such as different originating waveform (sin, sqaure, saw) or different filter (low pass, cut-off). thus, by saying that electronics sound is created by "electricity" and "creativity" is not entirely wrong. on the contrary, another way to create sound is "sampling" or "sample playback". this is done by first "sampling" the waveform from source audio, store it, and use osccilator to change the frequency (pitch) during the playback. this is similar to scaning a texture from real material and use it in 3D engine. if the analogy is texture reconstruction VS. procedural synthesis; then to sound it is, sound synthesis VS. sample playback. hope it helps. underexpose 01:51, 13 July 2006 (UTC)

[edit] Isn't this also used extensively in "Rogue-like" dungeon-crawling games?

AFAIK many rogue-like games (like Nethack or Moria) generate their dungeons "randomly"... Does this also fit into this category, and an someone confirm this? 193.96.240.2 08:24, 15 June 2006 (UTC)

I also think The Elder Scrolls II: Daggerfall may have used this process. The majority of its cities, landscape, and dungeons were generated at the start of a new game rather than beforehand. Zenithan 19:35, 25 August 2006 (UTC)