Can sin(x) be used for generating a starfield? I mean to tell me, deterministically where there should be drawn a star in my background, such that it will look good? So I do not have to keep track of their position? Any other functions that can be used for this?
And btw, I would like to consider the same thing for entities. (if possible). Like if you could just generate them, on the fly from running various periodic functions for their movement. I mean, I just saw this 4K demo that generates a mountain landscape, in 3d that looked stunning. So I was thinking maybe if you used more then one, you could generate most of the scenery like that, and turn them into real entities only when you need to interact with them or something. I dont know if even is possible. Just wanted to ask in case anyone here has experience with such a thing.
If I understand your question right, then yes. Using functions is a common method for generating procedural content whether that's textures (like a starfield) or heightmaps (like terrain) or 3D models, or procedural animation, or... well anything, I guess.
Sounds like you have the right idea, you can combine different transformations of a function to generate a more interesting output.
My first thought is if you use a periodic function like sin your content will be periodic eventually, meaning if you zoomed out enough you'd see a repeating pattern in your starfield or terrain. But I think if you change the transformations randomly over time or distance, then you should be able to avoid this?
More common is to use what's called a noise function. Perlin noise is the canonical example, but there's just no end to the different things you can use. Sin is a 1D function but you can use 2D, 3D, nD functions as well. One reason you might want to use a 4D function, for example, is if you have a 3D field of vectors that change over time (like wind). One thing I recently learned about from Casey is the concept of "blue noise" which is pretty durn neat... It's like white noise but less "clumpy."
I don't think I've seen someone use this concept for entity movement that I remember... like you said, I would think they'd have to be converted to a real entity at some point so they can be reactive. I have thought about how you could do this to generate like a whole city of npcs, for example, but I didn't get very far down the planning route.
Not really my area of expertise so I'd be interested in other thoughts. There's probably all kinds of cool stuff you can do. From my understanding this is basically how the demoscene makes all their content.
Sounds like you have the right idea, you can combine different transformations of a function to generate a more interesting output.
My first thought is if you use a periodic function like sin your content will be periodic eventually, meaning if you zoomed out enough you'd see a repeating pattern in your starfield or terrain. But I think if you change the transformations randomly over time or distance, then you should be able to avoid this?
More common is to use what's called a noise function. Perlin noise is the canonical example, but there's just no end to the different things you can use. Sin is a 1D function but you can use 2D, 3D, nD functions as well. One reason you might want to use a 4D function, for example, is if you have a 3D field of vectors that change over time (like wind). One thing I recently learned about from Casey is the concept of "blue noise" which is pretty durn neat... It's like white noise but less "clumpy."
I don't think I've seen someone use this concept for entity movement that I remember... like you said, I would think they'd have to be converted to a real entity at some point so they can be reactive. I have thought about how you could do this to generate like a whole city of npcs, for example, but I didn't get very far down the planning route.
Not really my area of expertise so I'd be interested in other thoughts. There's probably all kinds of cool stuff you can do. From my understanding this is basically how the demoscene makes all their content.
One thing that's worth mentioning about starfields is that if you're not moving through the star field (i.e. if you just want a celestial sphere), the easiest way to generate the stars is to generate them on the smallest enclosing cylinder (not including the end caps) and then project them back onto the sphere:
This, believe it or not, generates random points uniformly on the surface of the sphere. The theory behind the technique was discovered by Archimedes. According to legend, this was his favourite proof, and the image of the sphere and the enclosing cylinder was on his tomb.
1 2 3 4 5 6 | z = rand(-1,1); // random number between -1 and 1 theta = rand(0,2*pi); // random number between 0 and 2*pi r = sqrt(1 - z*z); x = r * sin(theta); y = r * cos(theta); // The point (x,y,z) is what you want. |
This, believe it or not, generates random points uniformly on the surface of the sphere. The theory behind the technique was discovered by Archimedes. According to legend, this was his favourite proof, and the image of the sphere and the enclosing cylinder was on his tomb.
From the demoscene, here's that 4k demo*, btw:
http://youtu.be/AWcbj7ksqwE
*And just to be clear: That is 4 kilobytes, not 4k video resolution.
The whole executable - including sound / music, graphics and motion - is only 4 kilobytes.
http://youtu.be/AWcbj7ksqwE
*And just to be clear: That is 4 kilobytes, not 4k video resolution.
The whole executable - including sound / music, graphics and motion - is only 4 kilobytes.
Edited by d7samurai
on
And since we're on the topic of procedurally generated content.. This is perhaps the pinnacle of the concept:
http://youtu.be/XLq5wOnsEX0
Farbrausch' famous .kkrieger beta - a full 3D FPS game that totals 96kb on disk. Everything in the game is procedurally generated. Levels, entities, meshes, textures, sounds..
Incidentally, one of the guys that did this works at RAD Game Tools, Casey's old employer.
http://youtu.be/XLq5wOnsEX0
Farbrausch' famous .kkrieger beta - a full 3D FPS game that totals 96kb on disk. Everything in the game is procedurally generated. Levels, entities, meshes, textures, sounds..
Incidentally, one of the guys that did this works at RAD Game Tools, Casey's old employer.
Edited by d7samurai
on
One more thing while I think about it. Deterministically placing random elements in a procedural texture is called "texture bombing". I believe the credit goes to Pixar, who used it to procedurally generate wallpaper textures in their 1989 short film Knick Knack.
If you ask your favourite search engine about "texture bombing", you'll get a lot of ideas about how you might pseudo-randomly place stars in a 3D star field, because it's just a higher-dimensional version of pseudo-randomly placing shapes in a 2D texture.
If you ask your favourite search engine about "texture bombing", you'll get a lot of ideas about how you might pseudo-randomly place stars in a 3D star field, because it's just a higher-dimensional version of pseudo-randomly placing shapes in a 2D texture.
So I do not have to keep track of their position
I think perhaps the OP wants a persistent, moving starfield. Something like
1 | StarPosition = GetStarPosition(int index, double time); |
where he can call a function, passing in a star index and a time, and have it generate that star's position for the given time procedurally on demand.
Edited by d7samurai
on
Pseudonym73
One thing that's worth mentioning about starfields is that if you're not moving through the star field (i.e. if you just want a celestial sphere), the easiest way to generate the stars is to generate them on the smallest enclosing cylinder (not including the end caps) and then project them back onto the sphere:
This, believe it or not, generates random points uniformly on the surface of the sphere. The theory behind the technique was discovered by Archimedes. According to legend, this was his favourite proof, and the image of the sphere and the enclosing cylinder was on his tomb.
Excellent. This is just what I need. I even find it to be easy to grasp, yet I would never come up with it, even though I understand it and have worked with both circles and degrees in code many times before. Can't wait to implement it. Thank you.
Edited by Livet Ersomen Strøm
on
midnight_mero
If I understand your question right, then yes. Using functions is a common method for generating procedural content whether that's textures (like a starfield) or heightmaps (like terrain) or 3D models, or procedural animation, or... well anything, I guess.
Sounds like you have the right idea, you can combine different transformations of a function to generate a more interesting output.
Nice. I really like the thought of this.
I have had daydreams about procedural bodypart generation, for years actually.. ;-D
midnight_mero
More common is to use what's called a noise function. Perlin noise is the canonical example, but there's just no end to the different things you can use. Sin is a 1D function but you can use 2D, 3D, nD functions as well. One reason you might want to use a 4D function, for example, is if you have a 3D field of vectors that change over time (like wind). One thing I recently learned about from Casey is the concept of "blue noise" which is pretty durn neat... It's like white noise but less "clumpy."
I read that a month ago, and wrote a simplified version. To my eyes his grass was too good looking!
midnight_mero
I have thought about how you could do this to generate like a whole city of npcs, for example, but I didn't get very far down the planning route.
d7samuraiSo I do not have to keep track of their position
I think perhaps the OP wants a persistent, moving starfield. Something like
where he can call a function, passing in a star index and a time, and have it generate that star's position for the given time procedurally on demand.
yes, but thats what i got too, unless I misinterpret. thanks for answers.
midnight_mero
My first thought is if you use a periodic function like sin your content will be periodic eventually, meaning if you zoomed out enough you'd see a repeating pattern in your starfield or terrain. But I think if you change the transformations randomly over time or distance, then you should be able to avoid this?
I am thinking maybe I could scale by distance to origo, or random points
Kladdehelvete
I even find it to be easy to grasp, yet I would never come up with it, [...]
Very, very few people are anywhere near as smart as Archimedes. :lol:
Can't wait to implement it.Yeah, about that. Square root and the trigonometric functions are two of the most expensive operations you can do, so you may want to consider some approximations. Implementing trig functions via table lookup with linear interpolation (for example) is probably good enough.
Hollasch's Law states that computer graphics is the only area of science where if it looks right, it is right. And Jim Blinn (of Voyager 2 encounter animation fame) always advised his students to follow the ancient and noble art of Chi' Ting.
Kladdehelvete
yes, but thats what i got too, unless I misinterpret. thanks for answers.
I'm not so sure. First of all, for that to be the case you would have to make sure that the random functions in that algorithm are seeded with the same number(s) each time you invoke it. Secondly, there is no 'time' parameter there to shift the stars' positions in proportion to (and no algorithm to do to the shifting, nor to determine a (consistent) variability in movement speed - to simulate starfield depth, since all the stars you have will be at the same distance from the center).
I didn't quite understand whether you just wanted an algorithm to render a static starfield skydome texture for a 3D first person viewpoint or something more dynamic like this:
2D / parallax:
http://youtu.be/mUrJukqyhIE?t=28s
3D:
http://youtu.be/MiaqtUKALJU
Edited by d7samurai
on
Pseudonym73
Hollasch's Law states that computer graphics is the only area of science where if it looks right, it is right. And Jim Blinn (of Voyager 2 encounter animation fame) always advised his students to follow the ancient and noble art of Chi' Ting.
Yeah. But who decide if it looks right? The "right" person? Let's hope it's not microsoft window 10 team, haha. God I hate that metro style thingy. It's obscenely ugly. Yes. Thats exactly what it is. To my eyes.