webGLmmk

Procedurally Generated Content - elements

6 posts in this topic

I'm sorry, I don't really have any code examples, since this is totally new to me. I want to start creating all my babylon scenes with procedurally generated content - I mean elements, not just textures. For example, this space scene with randomly distributed stars..

http://www.babylonjs-playground.com/#1PWCZ8#2

I can render quite a bit less if i just relocate sections as the camera moves forward. I'd rather start with another scene though, something simpler, like a "ground", moving tiles based on position of the camera - in fact putting it that way makes it seem even easier...(its never as easy as it seems)  I've started to read up on techniques, and I'm sure I can figure it out, but I thought I'd just shout out in case I've missed any nice examples in my forum searches. Most of what comes up is related to textures.

I'm not particularly concerned about materials right now, just environments and elements that are generated with movement. What I DO understand is that its a wide open field and how you procedurally generate depends entirely on what you are trying to create.

Been on hiatus for a few months, too busy but I'M BACK B

Share this post


Link to post
Share on other sites

Hiya @webGLmmk, welcome back!  Good to see you again.  Yeah... this "move the scene past the camera" (as opposed to moving camera through scene)... is an interesting theory.

MUCH is dependent-upon ... are you going to allow the user to freely navigate-around? 

OR... are you taking them on a guided tour, and user sits back and enjoys "the show".

Needless to say, the no-nav guided tour is MUCH easier (for live-genned scene items).

But if you allow user free-navigation, including up/down... then you must be prepared for user backing-up (reversing). 

When user reverses... there can be trouble.  You REALLY want to .dispose() the mesh/lights that the user is "leaving" (to get more CPU horsepower)... but... they are still dead-center of user's view (because they are reversing).  If you "pop-dispose" them in front of the user's view... well... that's just not normal or natural. :)  Perhaps gradually fog-over the forward view before doing the dispose()? 

"Yuh, yuh, yuh" (AL - from Happy Days).  LOD zones.  Radius rings.  And camera frustum stuff, too.  :) 

Let's pretend we have 4 circular "LOD zones" around the camera.  Pretend the zones... 0-100 meters, 100-300, 300-700, 700-infinity... away from camera.  IN the camera frustum (in-view)... all 4 zones-of-depth should/could be rendered  (user can see quite far, with possible lower rez on items in zones 3/4). 

It might be wise to design your dynamic model generators... with adjustable resolution, yes?  You never know which LOD zone/ring... you'll need to "grow" that model-within.  :)

I know-of 2 "continuous terrain" demos nearby, coded by active forum folk.  But, a good old-fashioned createGround works fine, too, right?

Ahhh... the cursor-up and "w" keys.  Our friends.  When I press cursor-up, am I moving the camera through the scene, or moving the scene past a stationary camera?  A big dog OpenGL/DirectDraw guy would say...  "you ain't doin' neither"  :D  Be well, talk soon, write back.

Share this post


Link to post
Share on other sites
17 hours ago, Wingnut said:

Hiya @webGLmmk, welcome back!  Good to see you again.  Yeah... this "move the scene past the camera" (as opposed to moving camera through scene)... is an interesting theory.

MUCH is dependent-upon ... are you going to allow the user to freely navigate-around? 

OR... are you taking them on a guided tour, and user sits back and enjoys "the show".

Needless to say, the no-nav guided tour is MUCH easier (for live-genned scene items).

But if you allow user free-navigation, including up/down... then you must be prepared for user backing-up (reversing). 

When user reverses... there can be trouble.  You REALLY want to .dispose() the mesh/lights that the user is "leaving" (to get more CPU horsepower)... but... they are still dead-center of user's view (because they are reversing).  If you "pop-dispose" them in front of the user's view... well... that's just not normal or natural. :)  Perhaps gradually fog-over the forward view before doing the dispose()? 

"Yuh, yuh, yuh" (AL - from Happy Days).  LOD zones.  Radius rings.  And camera frustum stuff, too.  :) 

Let's pretend we have 4 circular "LOD zones" around the camera.  Pretend the zones... 0-100 meters, 100-300, 300-700, 700-infinity... away from camera.  IN the camera frustum (in-view)... all 4 zones-of-depth should/could be rendered  (user can see quite far, with possible lower rez on items in zones 3/4). 

It might be wise to design your dynamic model generators... with adjustable resolution, yes?  You never know which LOD zone/ring... you'll need to "grow" that model-within.  :)

I know-of 2 "continuous terrain" demos nearby, coded by active forum folk.  But, a good old-fashioned createGround works fine, too, right?

Ahhh... the cursor-up and "w" keys.  Our friends.  When I press cursor-up, am I moving the camera through the scene, or moving the scene past a stationary camera?  A big dog OpenGL/DirectDraw guy would say...  "you ain't doin' neither"  :D  Be well, talk soon, write back.

OOOk... I got a lot from this, thanks. Lots of stuff I didin't think of.

In the space scene, they're supposed to have movement and camera control over 3 axes. (eye roll..skipping directly to the most difficult concept is my specialty).  Instead of relocating parent-child groups, simple create new ones and dispose...IF the player goes back a previous direction, they either see a different randomly generated group of elements -- or else I have the object stored in a global array and figure out a way to reference the correct index...Haven't thought that out yet...version 3.0 I"m thinking.  As few navigation options as possible for any other idea though.

As far as the view when the user is in reverse...or moving forward for that matter...zones are a good idea...may not be necessary depending on how much of the view the close objects are taking up. I mean the webGL canvas already shows diminishing perspective. The current element group would be big enough to occupy the attention of the player, and new zones would be created far enough before the edge of the current zone is reached.  That would still be saving GPU power. The problem with the scene I created is that the stars have massive particle systems, and I want ALL the stars to have particle systems, and that is way too intensive. There are the "really" far away stars that I could use a skybox or skydomes for...Never really loved how that turned out when I tried it before, but I just need the right texture. In that  case, navigation limits could be set (I assume?).

What If I have a rubix cube layout of star zones. Multiple array of grouped elements. Player is always in the very center. As soon as I reach one of the outside squares, the far column disappears and a new one appears on the side I'm approaching. Piece of cake ;)

Another thing I thought of, is increasing the size of objects as you approach them. A size gradient, with elements gradually smaller the farther they are away, and they increase as you move closer. To simulate a greater distance of objects, without increasing the number of meshes over a broader area. Feels like I'm missing something obvious there... The space concept is pretty forgiving though, because there are lots of dead zones in space. Which reminds me...fog wouldn't work in this scene, because it's space :D 

I mean it's a flipping non-photoreal, totally fantasy, webGL render, lets get over myself

So does LOD stand for Level of Detail? Had to google that but I still don't know what it really refers to in terms of 3D content. Basically like...the closer the objects, the greater the subdivision/high-poly?

Need to look back through Babylon docs again and look through camera classes and location stuff...navigation, control, etc. It's been too long, too too long.

 

 

Wingnut likes this

Share this post


Link to post
Share on other sites

haha.  You have SO MUCH playful personality and inventor's spirit... too cool.  If you don't mind, I'll point-out a couple issues.

First, depending upon the type of game, if user walks west from Hangar #9, and then turns around and walks east, you should probably, somehow, allow them to re-arrive at Hangar #9.  Now, Hangar #9 need not exist ALL THE TIME, render-wise, but... the number of craft stored there, the direction of its hangar doors, its location on the landscape, etc... is what REALLY needs to be stored. 

Your "hangar generator" code can repeatedly create flight hangars, (with SOME random differences in looks... hangar-to-hangar).  And each hangar has unique characteristics/properties.  You could call them hangar hard-traits and soft-traits.  Hard traits... general hangar shape, size, capacities, materials, repair speeds, etc.  Soft-traits might be... current aviation fuel, current # of craft, current # of personnel, food levels, first aid supplies, etc (all soft/variable values).

So, really, what you need to store is a DB record for Hangar #9.  These "SceneItem Class Objects"... could have a .type = "hangar", and when your "sceneItem generator code" sees that it is .type = "hangar", it uses the hangar-assembler section of the sceneItem generator.

OR... hangarClass objects could be a subClass of buildingClass objects, etc etc.  (Very OOP-based, like my friend @Temechon might do.  He has some nice tutorials at his home site, by the way).  OOP stands for Object Oriented Programming, of course, and yes, LOD means Level Of Detail.  But, for BabylonJS/webGL, 4 LOD levels... means creating 4 different models, each with different resolution (and having them in-memory, too, I believe, but not .enabled)   BabylonJS will automatically swap-out the models at whatever LOD-zone radii you wish to set.  This is a performance thing, not a visually-nice thing.  If you don't need the performance... let the webGL renderer naturally de-detail the model, with its depth rendering stuff, and use camera maxZ to boot it from the camera frustum... at a certain distance.  :)

8 hours ago, webGLmmk said:

but I just need the right texture.

For the skybox "far stars" textures?  Yeah, not easy to get skybox stars to look right AT ALL, and then to make them look right when mixed with mesh stars... hard to blend.  Remember to consider using a screen-grab image... of a full-screen view of your near/mesh stars (the non-skybox ones).  Everyone forgets to try grabbing 5-6 skybox images...  grabbed from their own screen (showing a BJS scene - possibly viewing the 10,000 mesh stars scene).  :) 

Also, be sure to search the forum for 'panorama'.  There's some folks who are using certain kinds of textures... mapped spherically, and getting some pretty nice 360 degree seamless backgrounds.  There's a bit of image-gather near the poles, avoidable by using camera beta (tilt) limits.  I think this is called "equi-rectangular projection" - here's a demo, another demo, and some more equi-pics.  [thread]

I like your 10,000 stars thing, too.  I'm a USE MESH kind of guy, too... but... as you likely know, 10,000 spheres can get a bit heavy.  :)

Particles are an option for "skydomes" too.  Here is a demo (you might have seen it before) that uses custom particle startPosition and particle update functions... to place the particles in a spherical pattern.  It uses some fancy Cartesian crap and spherical coordinates funcs stolen from the web, and it has some polar and equatorial "flocking" issues.  It could easily be converted to hemisphere, too.  That might be a way to produce lightweight starfields, too.  Imagine 4-5 of these particleSystems running at the same time, each rotated-around a bit to remove flocking problems, and each producing a different kind of star or planet.  Might look pretty good, and still keep its speeds.  Particles are "billboarded" and thus... always face the camera.

Back to structure generators... I think you should try to stay object oriented, if you can.  Base-class sceneItem, has a subClass buildingItem, which has a subClass hangarItem, etc.  Basic database items.  They are simple JS objects... with no mesh associated with them at all.  Perhaps each has a property called .mesh.  That property... references either a real BJS mesh, or a function that generates that mesh(s).  In this way, you have "detached" the rendering of the structure... from the data for the structure.  This separation will be very handy for you, as the project gets larger.  Not only that, but you can tell your database to "render as an HTML table" too... easily letting you view (all records or single record), and possibly edit... items in your "world database"... via a web page.  You could even view all the items in a plain ascii list.  It could even be rendered as a SVG/2D map.  The database is separated from the (many) methods of viewing it.  Handy.

Each database record... (each sceneItem) carries UPON it... all the values and "stuff" that the "hangar generator" or "tree generator" might need... to render THAT hangar or tree.  SOME properties and methods are inherited from their superclass, and some props/methods are only defined down at the hangarClass or other subClass. 

Sure, the tree generator itself could also do some randomizing... so all the trees don't look identical... but... things like .LODzone... are carried on the DB record for the item.  You will need fast searchers on your database utils... able to find all "zone#6" items in the database... fast  (if camera frustum just entered zone#6, for example).  Code must then either create all those mesh structures (only the structures in field-of-view), or them.setEnabled(true).  A busy time.  :)

Fun thinkings, eh?  *nod*.  A BJS scene is really an endless frontier of wide-open possibilities, eh?   Your mind is working fine, sniffing out the possibilities, about ready to try some tests.  I look forward to your playgrounds and other experiments.  This is going to be (continued) fun! 

Reminder - I'm no expert, and the suggestions I give... COULD be bad approaches or COULD contaminate your idea-flow.  At certain points, or perhaps at ALL points, it might be wise to ignore me.  heh.  Sorry for all the yapping.  :)

Share this post


Link to post
Share on other sites
15 hours ago, Wingnut said:

@TemechonFirst, depending upon the type of game, if user walks west from Hangar #9, and then turns around and walks east, you should probably, somehow, allow them to re-arrive at Hangar #9.  Now, Hangar #9 need not exist ALL THE TIME, render-wise, but... the number of craft stored there, the direction of its hangar doors, its location on the landscape, etc... is what REALLY needs to be stored. 

[...]

Also, be sure to search the forum for 'panorama'.  There's some folks who are using certain kinds of textures... mapped spherically, and getting some pretty nice 360 degree seamless backgrounds.  There's a bit of image-gather near the poles, avoidable by using camera beta (tilt) limits.  I think this is called "equi-rectangular projection" - here's a demo, another demo, and some more equi-pics.  [thread]

Particles are an option for "skydomes" too.  Here is a demo (you might have seen it before) that uses custom particle startPosition and particle update functions... to place the particles in a spherical pattern.  It uses some fancy Cartesian crap and spherical coordinates funcs stolen from the web, and it has some polar and equatorial "flocking" issues.  It could easily be converted to hemisphere, too.  That might be a way to produce lightweight starfields, too.  Imagine 4-5 of these particleSystems running at the same time, each rotated-around a bit to remove flocking problems, and each producing a different kind of star or planet.  Might look pretty good, and still keep its speeds.  Particles are "billboarded" and thus... always face the camera.

[...]

Each database record... (each sceneItem) carries UPON it... all the values and "stuff" that the "hangar generator" or "tree generator" might need... to render THAT hangar or tree.  SOME properties and methods are inherited from their superclass, and some props/methods are only defined down at the hangarClass or other subClass. 

Sure, the tree generator itself could also do some randomizing... so all the trees don't look identical... but... things like .LODzone... are carried on the DB record for the item.  You will need fast searchers on your database utils... able to find all "zone#6" items in the database... fast  (if camera frustum just entered zone#6, for example).  Code must then either create all those mesh structures (only the structures in field-of-view), or them.setEnabled(true).  A busy time.  :)

Fun thinkings, eh?  *nod*.  A BJS scene is really an endless frontier of wide-open possibilities, eh?   Your mind is working fine, sniffing out the possibilities, about ready to try some tests.  I look forward to your playgrounds and other experiments.  This is going to be (continued) fun! 

Reminder - I'm no expert, and the suggestions I give... COULD be bad approaches or COULD contaminate your idea-flow.  At certain points, or perhaps at ALL points, it might be wise to ignore me.  heh.  Sorry for all the yapping.  :)

 

Ok so I guess I have to get back on the Node train again, and related DB's. Pretty comfortable with all the OOP, but databases were always like, "I'll get to that when I need to get to that". Apparently that's where I'm getting to pretty soon. I think I did something with PHP/mySQL once lol. Who hasn't. Was never particularly anxious about the ability to figure it out when I needed to use it. You can cripple your productivity worrying about all the things there IS to learn..its better to just learn what you need when you need it.  I came across something called "Nodegame" that seems pretty promising. http://nodegame.org/. Obviously don't want a stack that's meant for standard webdev. Enough gamedevs doing this now that there hopefully will be something easier for me to jump into. [Here's the deal guys, gamedevs...you do all the hard work, and then I tweet about how awesome you are. thanks for the framework. Open source is the best.]

Yeah, any game idea I want to develop that's not a simple arcade style game will need to store it's objects in a DB. That I expected, though not as immediately. This star scene was never really meant to be a game, but it's probably a good way to build my skills.  I like the idea of using particles as distant stars. They'd need static positioning in this scene though...they're not going to emit from anything. maybe SolidParticleSystem.

No worries, I don't take it all as gospel ;) ...you do have a way of helping me think of things I haven't considered, so the brainstorming around to different possibilities has it's value.

Share this post


Link to post
Share on other sites

Cool.  Yeah, don't let the "database" part scare you.  Just collections or arrays... I sometimes refer to this document.  But really, you just need a buildingClass "factory", spawn 10 new genericBuilding(blah, blah, blah, blah, blah);  Push the returned objects into an array, and there ya go... test database complete.  :)  No need to give yourself a tumor right out of the gate.  :D  JS is magically easy... almost no rules.

And DOM is nearby.  What if... createElement("database") creates a <database> element?  Set its CSS display NONE, append to <body>, and then start stuffing it full of other made-up element names.  var building01 = createElement("building")... creates a <building> element.  Append to <database> element.  building01.xloc = "15", building01.yloc = "20"  (DOM attributes ONLY like strings as their dataTYPE, I think).  Anyway, that is another way to store your data. 

At render time, your "building generator" would parse that "tree", or "tree-walk" it, or... umm... XSL filter it (ahem!)... and return stuff.  XSL has lots of power... and its built-in to the browser so it's fast, and it can bring you ALL sceneItems in the tree... with attribute type = "hangar".  XSL is the regexp of dom nodes.  :)  JQuery probably has equal powers. 

It's an interesting project, no matter the lookup methods.  Essentially, you would be inventing WebGLmmk Markup Language v1.0, and a parser for it.  Weird idea, huh?  See why I lightly mentioned that your "world editor" could be a HTML form?

Okay, maybe that would be strange.  heh.  Possibilities, though.  JS can create and append generic XML-ish nodes, and can do setAttribute and getAttribute on those nodes.  (does anyone still use those?)  :)  Junk can be done.  Tree-walking/recursion.  Fun!

And yes, the standard Babylon particleSystem has an easy wedge-in point... to add your own custom startPosition func.  Then you disable about half of the particle updateFunction (to keep them from flying), also an easy wedge-in.  See this, as wanted.  It is a demo... with "the big 3 customizable particle funcs"... already hijacked into a playground... ready for demented experiments.  Essentially, these "big 3 customizables"... are the particle "engine". 

Many of the property settings of the particleSystem (such as .emitBox and .direction1/2 and .colors1/2/dead, lots more)... are utilized in these "big 3 customizables".  UpdateFunction (the funnest point-of-demented-hacking) runs fast and hard... continuously... so don't slow it down too much, or you'll produce oatmeal-speed particles.  It's a high-efficiency high-rpm blazer-func. 

http://www.babylonjs-playground.com/#1PQT7P#1  Lines 36-57... can you feel it vibrating the playground.... cuz it's going so fast?  *nod*  Radiating heat, too,  ;)  See that line 50 angular crap?  That spins the particle around its Z-axis... a waste of time for stars.  Might as well remove that line and gain 13 mph, huh?  COOOOOL!   Have fun.

webGLmmk likes this

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.