Infinite Procedural Terrain Engine


#33

New ver of your terrain works well.

Also DRWR posted some useful info on how Panda really works internally re: 32 and 64 bits. Seems there aren’t really ANY true 64 bit GPU’s and Panda cuts things down to 32 bits internally, this answered my questions regarding wasted space, seems Panda does not store vertices and other data sent to the GPU as 64 bits and that length is only used by python for intermediate calculations. The whole 32/64 problem was just the FPU getting mis-set by the graphics driver causing precision problems in Python, first really good explanation I’ve heard. Still, I cannot run geometry shaders like Craig’s GEOCLIP grass on this thing but I CAN do my grass clumps like Demomaster does in his grass demo 3.

Your terrain baking and texturing system is a LOT easier to understand than Craig’s and will make what I’m trying to implement simpler, with multiple height level texturing and slope texturing that will allow me to do cliff faces and a nice shoreline for the waterplane. I had almost turned Craig’s code literally inside out so as to get a splash screen and GUI up first, I’ve got a somewhat stable three viewpoint orbitable camera and an avatar with overhead text labels. As soon as I rework and objectify my X input joystick and GUI code, I’m going to try integrating it into your framework and start the process of adding the SQL databases for mesh placements.

P.s. Do you know if anyone has a version of Psyco for Python 2.7 available, I use it heavily and miss it now that I’ve upgraded to Panda 1.8

Best regards from the “dirty old fox”.


#34

Hey kitsune, I’m very glad you were able to get my terrain engine working for you. If you don’t like the way my engine generates mountains, it should be very easy to alter. I’ve separated out a “HeightMap” class that is soley resonsible for generating that geometry. There are a bunch of variables you can manipulate, or it should be easy to plug your own code in there too.


#35

I’ve been using Craig’s code so I’ve gotten familiar with it, but I personally think yours will work better for me… and its easier to understand and add in the tile cacheing and SQL Lite database mesh placement I need. Also I like the height and slope based texturing as it has more regions and is a lot easier to understand than Craig’s approach.

Now I just wish I could find a version of Psyco that works with the Python 2.7 underlying Panda 1.8 which I’m now using exclusively. I hope to have version 0.4 up on Google code sooon so youse guys can see what I’ve been up to. I haven’t tried your demo code with the new multithreading but I have with Craig’s code and it does not work like that as I think app/cull and draw end up fighting over posession of the GPU and it ALWAYS crashes befroe even drawing anything. Gotta try with your code next as being able to use both of my cores could give me a speedup even without Psyco.

Just tried yours with two threads… and IT WORKS, and it is faster. YIP! YIP!

Best regards Raven Gengoro Foxfire-Ninetails


#36

Craig has posted new terrain code that CAN create collision geometry for Geomip. Looking forward to getting my code, his new collideable ground and your shaders all working together.

Then I will put what I’ve got up somewhere. I currently have a world with a tracking waterplane two moons a sun and a two layer cloudy sky with nighttime stars and a multi viewpoint camera, I’ve replaced Ralph with Demomaster’s Fleur and she swims in the water, considering replacing some elements of my sky with yours as they look far better.

YIP! YIP!


#37

Sounds like you have made great progress lately. I can’t wait to see what you’ve done.

For my clouds I just found the highest res tileable image of clouds I could, converted it to a grayscale, then I use it as an alpha map and color it the same value as the sun light. Its alright but there’s really no depth to them. I’m thinking about hacking up a way to approximate directional lighting even though its just a 2d image.

The sun is just a tweaked clone of the one from Naith.


#38

My clouds are basically taken from the day night cycle demo but I changed the texture and implemented it as two rotating domes ( at differing speeds )instead of just one, I also replaced the cheezy night stars with a Hubble image also replaced the mopath sun with the same sort of “orrery” like spinners most folks use for their Dlights as the mopaths didn’t scale properly when I resized the skydomes. My clouds still have seaming problems which is one reason I was looking at yours, I also spun up two moons, I’m still not done fixing my multiviewpoint camera or the joystick code on this one and now am seriously considering dropping the whole framework based on Craig’s terrain demo in favor of one based on yours but adding back in MY move task and cam code plus Craig’s new version of the ground factory as I want something like that but running your renderer.Syill I probly should post "ol 0.3 just so u can see how awfull and un OO my Python is. LOL Also I have my waterplane rigged to track the avatar around and have taken many long walks out to the point where 32 bit FP precision issues begin. But I’m working on a fix.

regards,
“the dirty old fox”


#39

Well, this may go without saying but to fix the floating point issue with my engine I would wait until the player hits some threshold. Then just subtract the vector position of the player from everything, but add it to a variable worldPositionOffset or something. Then add that offset to the terrain’s getHeight function so terrain continues uneffected by the shift.


#40

Thats pretty much my plan, add an offset that periodically changes. This will keep everything positioned within the 32 bit FPU sweet spot and since all object positions will be relative to the cached terrain tiles this will have the side effect of making my databases more storage efficient as well and also allow me to wrap coordinates for round or toriodal worlds without the complication of having objects crossing signed boundaries at the wraparound point.

YIP! YIP!


#41

Every time I run your baker the terrain changes even if I pass a value to it as id = 666 for example. Looked at Python docs seems id is a builtin function that returns the internal id number of the object, which obviously changes every invocation. Seems this collides with your useage, Idle highlights id as purple just like True, False etc. Going through and changing it to terrainSeed. Hopefully this works OK.

Tried to transplant your terrain code into my original framework based on Craig’s code and ran into another gotcha. Even after straightening out the difference between the height functions I have two odd glitches one is that the texturer fails totally resulting in blank gray geomip tiles and two the returned heights always totally crazy, leaving me 3000-90000m ABOVE the terrain.

I’m going to have to ZIP up what I’ve got and put it somewhere you can get at it, have Google code and GIT but can’t figure out how to use them.

I don’t want to toss my whole framework, I have a cool bottom nav bar, an avatar with swimming action, a tracking sky with clouds sun moons and a tracking waterplane. And a mostly operational 1st 2nd 3rd view cam with orbit and joystick interface.

Going back to a copy of your framework to try the “id” mod to see if I get stable terrain tho.

YIP! YIP!
the “Dirty ol Fox”


#42

Tried the modification on an original copy of your engine. Terrain is still totally random and different every time, perhaps this means that the randomness is getting introduced inside the Perlin noise functions themselves, IDUNNO. It does however mean I will have to look into the possibility of grafting your texturer shaders on top of Craig’s bakery. For what I’m doing I need consistent terrain to generate, right now as it stands its like that Phillip Jose Farmer novel “The Lavalite World” I need the slope thing for cliff faces and your system seems easier to expand the number of texture levels than Craig’s. Also I should be able to adjust the snowcap level based on latitude easier than with his scheme which I just find too hard to understand let alone modify.


#43

Sorry for not responding for a month! I’ve been a bit busy for programming lately. I noticed you’re right about the terrain always randomizing. It turns out I did something very stupid causing one layer of each perlin noise stack to always get a seed of 0, thereby causing it to randomize itself. I’ve committed a fix to the repo.


#44

And I looked and looked at that but couldn’t find it, knew something was wrong tho, Thanx,


#45

It would slow down generation again, but have you considered integrating procedural trees (ala the demo) and grass placement? They could have a pop-up distace well short of the terrain itself as long as the “ground” colors match fairly well. Also, is there provision for setting a water table height and having river bottom/sea floor textures for regions below it?

  • dNN

#46

Those are the kinds of things I’m working on adding now. Moving over from Craig’s infinite terrain code to Steven’s I’m having to also redo my mouse and camera code, had a three view orbitable camera I now have to rework and gamecontroller/mouse integration ( Logitech F310 X controller ). Currently reworking the skydome to redo my two moons and nighttime starfields. Have been adding onto the terrain populator as well to add more species of trees and plants, and also not to plant them under the water. Lots of improvements that all take time. I work second shift in a warehouse and have a long bus ride to and from so most work is done mornings anbd weekends, hoping to soon have everything done and be getting back onto doing terrain SQL databases editor and multiplayer P2P networking code. Its a big project and currently I’m it as far as programmers here on the FoxyWorlds version of this engine, If it wasn’t for Stephen and Craig I wouldn’t even be this far. Also teaching my GF Tanzzy Lightningtails to code Python.

TTFN
“the dirty 'ol fox”
hoping to put up a zip of it all soon


#47

Edit: D’oh! I only just realised that LGKitsune, who just replied, wasn’t the OP! Oops… Still, most of this still holds true.

Also, while I’m not familiar with that specific controller (and need to rush off to an appointment rather than googling it and getting distracted again ATM) my own plan is to target to a standard Playstation-style gamepad with kbd/mse as a fallback; controls being most similar to Kingdom Hearts or the Traveler’s Tales LEGO games.


That sounds great - and I can certainly understand being the only person on a project :wink: Just to complicate things even more, have you considered ways to scatter random settlements? (I’m going on about this because procedurally generated planets for an infinite game-universe feature heavily in the game design documents I’ve been working on sporadically for… good grief, over a decade now. And yet, I don’t have a better project name than Ninja Robot Space Fighter…) The procedure I’d come up with (no code involved, just the logic) was to have a base point be created at fairly rare intervals, that would then engage a seperate module from the base terrain generator to create a street grid, populate it with buildings and a few NPCs (shopkeeper NPCs being inside their instanced shops) and then find a 2d n-gon that describes the outlinbe of the settlement, find the mean altitude of all terrain geometry within that n-gon, and flatten it to that level, using a second border region with the same n-gon scaled 2x to transition from the values of the procedurally generated terrain and also to kill procedural plant and monster placement so there’s a clear zone around the settlement.

I also have a rather extensive flowchart for generating infinite sidequests for those NPCs, but it’s too complicated to remember off the top of my head and those game files are on a laptop I have to try to ressurect from CPU fan failure when the replacement arrives sometime next week. I shall be rather put out if the operation is not a success; that machine’s optical drive failed over a year ago so there’s no backup of a lot of the contents, including some of my best transforming mecha models.

To get back on the point, your generator seems to be focused on fairly mountainous/temperate-to-semitropical terrain right now. and setting it up to make sand dunes or arctic steppes would probably require considerably different settings to the algorithm. Genrating an earthlike planet, though, requires numerous different climate/terrain types and large patches that are just ocean, so I’m proposing a simple sphere-unwrap that would be a planetary-level overmap (which could also serve as the view from high altitude/orbit) which determines which set of regional terrain generation settings are used based on the pixel the generated ground-level terrain corresponds to. Experimenting with the procedure and shader settings to make different terrains to actually apply would be the challenge from there…

I’ve just started with Python, with 1/2/3/400 level C courses and intros to Java and FORTRAN now several years behind me, so I’ve got quite a ways to go before I’d be able to help in any meaningful way with coding. I’m primarily a 3d modeler, as well, with only a few forays into texture maps as far as working with surface materials is concerned - figuring out how to do environment mapped reflections in Blender was a big step forward recently. All the same, this and MV3D look like the the Panda projects most likely to be useful as the foundation for what I want to do, so as I (hopefully) get up to speed in the code-oriented aspects they’re what I’m likely to work from, and of course will return my tweaks to the community. My installation is v1.7.2 right now, though, so I guess I’ll have to upgrade - not being too confident in my coding I wanted to stick with the stable release.

  • dNN, tends to run on a bit

#48

Yeah I even looked at MV3D as a way to get things up faster, but could never even get it to run… also its based on an earlier ver of Panda/Python and I’ve already upgraded to the latest ver ( 1.8/2.7 ).

I'm doing this in a layered approach, as soon as I'm done fleshing out Stephen's terrain populator with more tree and plant species and giving it the ability to set where they can appear ( latitude, altitude, slope and so on ) so they don't grow out of the water ( except for cattails and mangroves ) I want to add in a very few of Craig's procedural ferns and treetrunks to spice it up as well as some egg model palms etc. These tend to be more CPU intensive so will use sparingly.

Then I move on to adding SQL Lite DB files and cacheing to the terrain tiles, procedurals can be serial numbered into the DB so land can be "cleared" for roads and buildings. I'm wanting to do a "Sim City 4" like terrain editor that can modify the cached heightmaps. You have obviously been thinking along similar lines for some time, so I hope your "data recovery" goes well. As for your usefulness, you are undoubtable farther along in understanding Blender and your knowledge of C++ would be very helpful when it comes time to put all this Python code thru Cython and generate a faster C++ version of the app. But this probably won't happen till the distributed P2P networking layer is done with Twisted Core and Entangled.

Also I need more of the game logic in place, asset packaging and so on. I've spent a few years working on design as well see here:

sites.google.com/site/foxyworld … hitepapers

My eventual goal is to totally destroy the economics of “virtual land” as they exist on totally server based sites like Second Life. $9.95 a month for a squtty little 25 meter square with only 1500 primitive objects is just outrageous price gouging and limits VR only to those with a credit card. UNACCEPTABLE

sincerely,
Lord Raven gengoro Foxfire-Ninetails


#49

… wow dude, you’re bitter. Also, and not to be insulting, but magenta-on-black is perhaps not the most readable of website color schemes.

Your whitepapers go a lot more into the technical aspects (which is important) where I’ve mainly got content-related stuff like the various special abilities (magic, martial arts, etc.,) user-level interface function, the game system in the tabletop-RPG sense, a 3000 year plot for 1p/co-op Story Mode (the Prologue shows your character being created as one of a more-intelligent Star Wars Ep1 style robot army and having the responsible would-be-conqueror wiped out by government forces, then get assigned to a civilian contractor (read mercenary company, the replacement for fantasy-mmo guilds) who’ll try to integrate you with regular society while turning your skills to a marketable use. Customising or replacing your body is one of the core mechanics so you have no fixed lifespan;) a couple of minigames, that kind of thing. I also had a good dozen or so character and enemy models on the dead computer, but can’t find the one thumb drive I’m pretty sure I’d backed them up to recently, jammit.

Regardless, we shouldn’t hijack the thread for talking about our stuff, I suppose, where it doesn’t have relation to terrain generation. I’ve pretty much already covered everything relevant to that, so I’ll stop now.

ETA: Inspired by your whitepaper listing for non-spherical and outer space worlds (even though it’s just a “To be done” my system of having an overworld map that controls terrain gen by which pixel your location corresponds to would also apply there - just define how the cartesian texture map applies to the nonstandard shape, and as the user travels from one area to the next they’l automatically move around a whatever world shape you set. The only real issue would be working out how to tell the skybox to put in the other side of the ring when it should be overhead - though at least the overmap would make sure you already had a texture for it.

One possibility would be to actually create an example of whatever the world shape is and use render-to-texture to put it into the skybox - it would of course be FAR FAR beyond camera cutoff to just put the thing literally into the sky. This system would make it relatively straightforward to use, though. My own favorite shape for a world comes from a paper model I once made of a bunch of tetrahedrons assembled into a hollow tessellated icosahedron with a few of the faces missing so you could get into the hollow interior. I don’t at this point, remember how many or in which positions, but about thirty seconds looking at a d20 would solve that.

ETA2: Don’t be too impressed by my C courses - only the 300-level even touched on the basics of 2d graphical interfaces. 400 was entirely about data structures and manipluating them, IIRC… basically what having taken them means is that I know how to read an API document and can usually get the examples from one to work using my variable and function names, after a suitable amount of… “incantations” and time.

As to modifying the generated terrain, I’ve never actually played any of the Sims games so I don’t know what you mean by “Sims-Like” but essentuially all I’m saying in my previous post is that you have XY patch of “ground” that’s defined as flat or by a height map, and spot it into your infinite procedural section by defining a zone around it where the z-values get mixed from one to the other - like the way a soft-edge brush transitions from the background color to the active color using alpha mixing, or texture splatting on terrain image maps.

Exactly like texture splatting on a terrain image map in fact, if you’re using a height map. I’d expect a similar fuction to be necessary to transition between overmap-pixel regions.

  • dNN, rock on!

#50

I apologize for further thread hijacking, but I feel somewhat strongly about these three issues:

People have said this before - I really think you should take notice.

And, from the FoxyWorlds TOS:

If FoxyWorlds is truly open-source - according to the OSI’s definition- you cannot keep this part of the TOS (see clause 1, “Free Redistribution”, and clause 7, “Distribution of License”). As a matter of fact, that part of the TOS is, in all likelihood, legally invalid.

Also, from another part:

This part is probably also legally invalid since it goes against clause 6 (“No Discrimination Against Fields of Endeavor”) of the OSI’s open-source definition.

Please don’t take this the wrong way - I just wanted to make sure you knew there were a few problems with your TOS.


#51

First I do have another thread open maybe we should use it for discussing my version of the infinite terrain.

[url]new project FoxyWorlds]

As to the color scheme two things:
1) the magenta on black is kinda our thing to visually differentiate us from all those black on white “standard” pages
2) About 8 yrs ago I suffered a ruptured cerebral aneurism ( 75% fatality rate ) this sort of page is a lot easier for me than the standard black on white which causes me eyestrain, wish I could figure out a way to get Idle to do it for coding.
3) it aint gonna change … so quit whining, be glad Google won’t let me put it in our chosen font of “Mistral” LOL

As to the TOS/License:
1) the split personal/commercial license may well be undefensible under OSI, but IF somebody else DOES make money off of it I’d like to at least see a “donation” so I can continue the Work.
2) I have seen similar terms about weapons systems on other packages in the past, again these were probably indefensible as OSI but maybe not as a TOS???
3) I do include a “severability” clause for that very reason.

Right now I’m still migrating things from the previous ver using Craig’s terrain to Stephen’s version and am having a time of getting features like floating avatar labels and chat text areas to work and don’t fully have my camera controls integrated with his. Mouse and keyboard controls still in the rework as well.

Hope to post a ZIP of the current demo as soon as I get these done.


#52

Great work! I’ve tested the browser demo, a bit laggy when using boost mode, but when walking normally there’s not a single lag, which is pretty amazing for a browser demo!

However, the source code repository is down. Any chance to get it somewhere else?
github.com/AnimateDream/Panda-3 … ain-Engine