Making trees

[TomorrowPlusX]

I'm looking to spruce ( it's a pun, laugh ) up my environment by adding trees to it. Now, I'm perfectly capable of using wings3d to make simple trees, but frankly, automated systems with tweakable parameters will do a better job.

My questions are:

1) Are there *free* packages that are reasonably good?

2) If not, are there affordable non-free packages? By affordable, I mean a lot less than $100 US.

3) Should I just break down and write my own generator :cool:

My main issue is that while I'm a well-employed adult, game dev is my pasttime, and I don't have the money to buy Maya or some other professional package. That said, I'm decent in Wings3D and I can learn Blender.

Also, it would be nice to have the foliage/leaves be separatable from the trunk. I'm using stencil shadows, and I don't think that single-sided leaf quads will work too well when performing silhouette determination. So ideally I'd have one trunk model which is a closed solid, and a second model which is basically a list of quads and texture coords.

Oh yes, it would be nice if I could get nice textures too, procedurally created ideally.

Can anybody help? If I have to take path #3, this is the kind of thing I could spend months on. Fun, but not my primary goal...

EDIT:

I just found this: http://www.geocities.com/blenderdungeon/lsystem/index.html

But it's four years old, and several blender revisions back. I don't know if it would still work, and I'm not proficient with blender enough to know how to make it work if it doesn't.

EDIT2: I've futzed, but I have zero experience with Blender's scripting. It doesn't work, it chokes on importing basic python libs, like string and math.

[TomorrowPlusX]

I decided to make my own trees... I've decided to go for a continuous randomly generated forest. As in, every tree being unique and randomly generated following configurable parameters.

Over the weekend I worked out the algorithms on paper and began writing an "editor" for developing trees. I don't actually have trees yet, but the underlying datatypes and editor are working.

http://zakariya.net/shamyl/Trees/Screenshots-2005-10-31-00.png

Stay tuned...

[Leisure Suit Lurie]

Wow. Its like Reubert's weed growing game...on a much larger scale.

Gorgeous looking. Nice job, man.

[TomorrowPlusX]

Thanks, but I don't have any trees yet -- just an editor for changing parameters, and a "Tree" object which has an empty generate() function. But, the infrastructure is done, now I just have to make the tree actually build itself.

[TomorrowPlusX]

It begins...

http://zakariya.net/shamyl/Trees/Screenshots-2005-10-31-02.png

[blobbo]

If this were Darwinia you'd be finished ;)

[TomorrowPlusX]

As of last night I've got solid, shadow-casting geometry. No leaves yet, though.

http://zakariya.net/shamyl/Trees/Screenshots-2005-11-01-03.png

http://zakariya.net/shamyl/Trees/Screenshots-2005-11-01-04.png

http://zakariya.net/shamyl/Trees/Screenshots-2005-11-01-05.png

Once leaves are in I can probably bring down the recursion depth quite a bit. It's easy to make *really* complex trees which bring my computer to its knees...

[blobbo]

I really don't want to be impaled on one of those ;) Yup, some leaves or texture would make it look more real :)

[Leisure Suit Lurie]

Is that the Tree of Woe?

More importantly, will we be able to race riding lawn mowers in this?:p

[TomorrowPlusX]

Now, with texturing and "leaves". By "leaves", I mean I've got textured quads up but I haven't actually drawn the texture yet, so it's a green square :P

http://zakariya.net/shamyl/Trees/Screenshots-2005-11-02-12.png
http://zakariya.net/shamyl/Trees/Screenshots-2005-11-02-20.png

[Nick]

That's so cool that you can make formulas and equations that figure all that stuff out and just make trees. They look awesome. Good job.

[blobbo]

Now if you make the trees leaves change colours and fall from the trees, that'll make you a true guru. ;)

[TomorrowPlusX]

I'm no guru. OSC and arrekusu are. I just work hard.

[TomorrowPlusX]

Well, I spent the weekend finishing the implementation. It took some work, and while I'm not "done" yet ( I still need to make good textures, and whip up a number of good parameter scripts ) I now have a system for continuously generating trees on the fly as you move around. I also have a separate implementation ( which is faster ) which clones from a set of 64 "prototype" trees, based on four parameter sets.

Anyway, the point is that you can move around and for all intents and purposes, my environment has *thousands* of trees in it, each being a shadow casting, collidable 1st class entity in my scenegraph ( though it only exists if you're near it ).

Here's some shots:
http://zakariya.net/shamyl/Trees/Screenshots-2005-11-07-12.png

http://zakariya.net/shamyl/Trees/Screenshots-2005-11-07-10.png

http://zakariya.net/shamyl/Trees/Screenshots-2005-11-07-08.png

http://zakariya.net/shamyl/Trees/Screenshots-2005-11-07-06.png

The neat thing is that while the trees are created as you approach, since they use a reproducible seeding algorithm you'll always get the same random tree in the same place!

[blobbo]

Just phenomenal. These screenshots just blow me away - this looks like a professional calliber game. Really.

Got a build we can play around with? What's the gameplay going to be like?

[TomorrowPlusX]

Right now, there isn't any gameplay... just free movement with barely any collision detection. That said, everything visible except grass is a collider.

My plan for gameplay is going to be a mix of vehicle driving ( outside ) and 1st person. I've already got a fairly robust framework for vehicle support from my aborted previous game and it's just a matter of porting it over to my new engine. Regarding first person, I'm planning on making it *super* realistic, with your character being able to slip and fall if on a steep ledge and so on.

My game -- and this is mainly the result of talking with my friends over beers -- is still in the concept stage, but here it is in a nutshell.

It's called "At the Mountains of Mars" and is based off the Lovecraft novella "At the Mountains of Madness" which is about an ill-fated expedition in the 30's to antarctica, and what they discovered there.

There will be *no* weapons. The game is about survival and escape, pure and simple. You're a driver, delivering parts to the Starkweather-Moore ice-mining expedition on a mostly terraformed Mars ( you can get around, but you need to breathe easily ). On arrival you discover the outpost to be destroyed, and everybody dead, with wreakage and destruction leading to an ominous pit in the ice cap. You drive in to try to find survivors and an avalanche traps you inside...

There won't really be hit points, only the idea of maintaining your sanity and heart-rate, since you'll only have a limited amount. The shit that goes on in the caverns is going to be *scary*, in principle, and you basically just want to get out and notify your colony to get the hell off the planet.

If you've read any Lovecraft you'll understand the general idea. In terms of feel, I want it to be something like Silent Hill 2 but 1st person.

So, it's big plans, and I'm having fun building the engine.

[Taxxodium]

All it needs is some good background music *hint* *hint* :)

[skyhawk]

I want this for my program! do you plan to make this available for outside use? I am very curious as to how to do this type of code

[TomorrowPlusX]

I want this for my program! do you plan to make this available for outside use? I am very curious as to how to do this type of code

Actually, I intend the engine to be open source, something liberal like the MIT license.

If people are interested I'll start posting builds.

[Nick]

Actually, I intend the engine to be open source, something liberal like the MIT license.

If people are interested I'll start posting builds.
I'm really interested not really to use it (:ninja: though I might:ninja:), but rather just to see how you handle your heightmap and how you do all the grass, trees, particles, and everything else cool you have in that engine.

[unknown]

yes, thats fantastic of you, Im sure I will learn many clever tricks from you reading the code. Thats very kind TommorowPlusX, and I look very much forward to trying it out.

edit: heh, Im listening to the Silent Hill 2 soundtrack right now.

[TomorrowPlusX]

Updates... I added support for multipass rendering of the tree foliage ( per the suggestion from NicholasFrancis in my "Continuous Vegetation" thread ) and now my trees look pretty sweet.

http://zakariya.net/shamyl/Trees/Screenshots-2005-11-09-00.png

http://zakariya.net/shamyl/Trees/Screenshots-2005-11-09-02.png

http://zakariya.net/shamyl/Trees/Screenshots-2005-11-09-04.png

Regarding releasing the source, I'll put a build up soon. I've got some minor edge-case details which I've still got to iron out. Not to mention it's nowhere near a complete engine yet, considering there's a lot missing and there's a lot on paper which I still have to implement.

But that said, it does some -- I think at least -- clever stuff, and might be a useful tool for people or at the very least might help people see a new approach here and there. The source ( and headers ) are heavily documented and I've got full doxygen docs for nearly every class. I believe in stiff, uncompromising documentation.

[unknown]

That looks so beautiful, hopefully if we do end up living on one of Jupiters moons, its going to be just like that.

[blobbo]

Gorgeous. Yes, I'd love to try out a build. So rare to have a developer that can produce beautiful art as well. This just looks fantastic.

[TomorrowPlusX]

Gorgeous. Yes, I'd love to try out a build. So rare to have a developer that can produce beautiful art as well. This just looks fantastic.

Thanks, I majored in painting & printmaking... the whole programming thing is just an obsession in my free time.

When I've got certain details ironed out I'll post a full source package + runnable build.

[TomorrowPlusX]

That looks so beautiful, hopefully if we do end up living on one of Jupiters moons, its going to be just like that.

My only regret in life is to have been born just too early to get to take part in space travel. When I was a kid I really thought I'd get to go to space by the time I was an adult.

... looking around...

Nope. Stuck in an office in Washington DC. And I ride my bike to work, no jetpack even!

[monteboyd]

Hey TomorrowPlusX, just wanted to say that I think what you're doing is amazing.

Not only does the engine look totally awesome but I think that game concept manages to be really original while using a classic sci-fi theme.

So keep plugging away at it! :D

[TomorrowPlusX]

Hey TomorrowPlusX, just wanted to say that I think what you're doing is amazing.

Not only does the engine look totally awesome but I think that game concept manages to be really original while using a classic sci-fi theme.

So keep plugging away at it! :D

Thanks, man. I appreciate it. I happen to love sci-fi, Lovecraft, and adventure games, so it all sort of makes sense.

Regarding releasing source -- my goal is to have a working 1st person mode before I release anything to people. Mainly because I need to build stuff using the engine to work out design and implementation bugs. Building a robust 1st person system will tax the physics integration as well as the overal design philosophy of the system, so I think it's worthwhile before I make the code public.

Also, I'm sorry to say, the cool particle effects from my "Explosions" thread from long ago ( http://idevgames.com/forum/showthread.php?t=9354 ) haven't been brought over to the new engine yet. I had problems with the emitter design when dealing with rapidly moving objects, and I intend to investigate how best to implement it before I bring it across.

[monteboyd]

Thanks, man. I appreciate it. I happen to love sci-fi, Lovecraft, and adventure games, so it all sort of makes sense.

Hope this isn't too OT - yeah I've read a little of Lovecraft, my favourite of his short stories are The Outsider and Rats in the Walls. I think there's probably a lot of scope for original gameplay and more story-driven games within the horror genre.

Clive Barker would be my favourite horror author, unfortunately the game he was involved with, Undying, didn't take enough risks with the ideas he had, it was too much of a first person shooter. I think the clever gameplay ideas in it had more potential. For example - you could perform "Scrying" whereby for a short time you would see events of the past in the area you were exploring overlaid on your vision. This was basically used to progress the linear storyline most of the time but I could see a similar technique being used in a game where the goal is to solve a mystery, rather than just shoot things.

Anyway, thought you might want to check it out (if you haven't already) for some inspiration.

[skyhawk]

Actually, I intend the engine to be open source, something liberal like the MIT license.

If people are interested I'll start posting builds.
That would be most wonderful! I would love to play around with such a thing. maybe implement such a thing into unity too (though I'm sure someone *cough aaarku* will beat me to it).
I don't know, I just see something like this being very useful. Keep up the AMAZING work.

Cheers! :love:

[arekkusu]

10% inspiration, 90% perspiration.

Looks awesome, keep it up. :)

[TomorrowPlusX]

Praise from Caesar!

...in my comment about you and OSC being gurus, I certainly didn't mean to imply you guys don't work hard :p

Anyway, thanks for the support. I'm busting my butt on this!

[TomorrowPlusX]

Some updates -- I've implemented crappy, crappy water. I played OSC's Outnumbered and it made me realize just how much I want a water system for my game. SO I went and did it.

The thing is, my powerbook has the worst graphics card in the industry -- the 5200 Fx Go, and as such, I chose to limit myself entirely to the fixed-function pipeline. Sure, it'd be nice to have fragment shaders, but they are SO SLOW on my machine that it just isn't worth it.

Anyway, given the limitation, I think it looks pretty good. I do some complicated per-vertex coloring to get sky color reflection, as well as transparency modulation based on distance from the ground and the obliqueness of the camera angle. I even did splashes that track objects that intersect the wave function.

http://zakariya.net/shamyl/Water/Screenshots-2005-12-06-18.png

http://zakariya.net/shamyl/Water/Screenshots-2005-12-06-20.png

http://zakariya.net/shamyl/Water/Screenshots-2005-12-06-27.png

http://zakariya.net/shamyl/Water/Screenshots-2005-12-07-16.png

http://zakariya.net/shamyl/Water/Screenshots-2005-12-07-17.png

http://zakariya.net/shamyl/Water/Screenshots-2005-12-07-19.png

[unknown]

Looks fantastic, sounds really inventive too. Most impressive.
What is the SPS in the top right if you dont mind me asking?

[TomorrowPlusX]

SPS = "Steps Per Second" -- I try to keep the world's state updated at 120 hz, dropping frames if necessary.

[Volte]

<chant> Build... Build... Build... Build </chant>

Looks cool as usual.

[PowerMacX]

Looks great, I imagine it looks even better in motion. That said, have you considered "fake" reflections? (ie drawing the geometry upside down and blending it with the water surface)

[OneSadCookie]

FWIW, Outnumbered doesn't use any shaders or anything like that. I use two features beyond OpenGL 1.1 -- VBOs, without which performance is too low, and a cube map for the skybox (more convenient than using 6 separate textures, but totally unnecessary).

[akb825]

Looks great, I imagine it looks even better in motion. That said, have you considered "fake" reflections? (ie drawing the geometry upside down and blending it with the water surface)
I would have recommended that as well, but I saw it was already running at 14 fps, and he didn't want to try out shaders because they would be too slow. I think drawing everything twice would push it over the edge.

[TomorrowPlusX]

I would have recommended that as well, but I saw it was already running at 14 fps, and he didn't want to try out shaders because they would be too slow. I think drawing everything twice would push it over the edge.

Exactly!

That said, in release mode with all settings at max ( including 2-pass lighting for shadows ) I get about 20 ( in the worst case, 25 or so on average ), and with all settings at minimum, I get about 40-50.

Anyway, I wouldn't be happy with the inverted-z reflection if it didn't purturb with the wave function -- and to do that correctly I'd have to render to texture and at the minimum I'd have to run a vertex program to perturb the texture coordinates by the vertex normal.

My goal is to get reasonable performance on *my* machine -- which is a 1.3 ghz 12" powerbook with a 5200. That means I have to keep it simple. I'd love reflections, but it ain't gonna happen...

[blobbo]

Just Phenomenal. I just love getting news on your engine - it's fantastic looking!

[staigerman]

I find that Carrara Studio 3 and more recent versions have a great Plant generator. I have a tutorial of some sorts in here:

http://www.thebest3d.com/carrara/plants

The first part is based on Carrara Studio 3, which comes on a hybrid CD for Windows and Mac. Even though it's about 2.5 years old (the latest is Carrara 5), it runs on Tiger 10.4, I know a film maker kid who's got it on his G5 iMac.

Carrara's plant objects are simple to use yet also immensely versatile, with tremendous options for the creation of the shapes and geometries, and then even more for the mapping and application of shaders. With that in mind, you can create awesome sprites and images with alpha channel masking for use in your games.

I would also recommend Project Dogwaffle, for its ability to make grass and other foliage, but it's a PCwin application. However, if you have Virtual PC on your Mac, I would love to hear if you can use the freeware version.

http://www.thebest3d.com/dogwaffle/free

Here are samples that are by game developers or oriented towards game dev:

http://www.thebest3d.com/dogwaffle/dotm/burt
http://www.thebest3d.com/dogwaffle/dotm/thegamesworks
http://www.thebest3d.com/dogwaffle/whatsnew/3_5/optipustics_new.html

particle brushes can now render the alpha mask simultaneously.

Then, you may have Painter, or other imaging/painting programs. Some of them have support for animated brushes, aka hoses (Gimp) or tubes (PSP). DigArts makes the Jungle DVD for game artists, as well as textures for low-poly mountains and other backgrounds. You might find it a good collection to create various types of shrubbery.

http://www.gardenhose.com

[TomorrowPlusX]

Re: staigerman
The vegetation brushes look excellent. I will have to look into them more closely. I'm reasonably happy with my geometry generator, but frankly, my vegetation textures suck ass right now...

[staigerman]

Re: staigerman
The vegetation brushes look excellent. I will have to look into them more closely. I'm reasonably happy with my geometry generator, but frankly, my vegetation textures suck ass right now...

Which ones you mean, those generated by Project Dogwaffle's particle brushes?

[funkboy]

It's great to see new screens of your engine. Very inspiring.

One thought about all games with water: where the water meets the ground. Is there anything you can do about that? Either by making the ground automatically take on texture modifications that make the ground "damp" (maybe just reducing the brightness of the textures that were just uncovered recently from the water), or even possibly make a little crashing against the wall?

The waves that appear when you intersect water with the object is similar to waves crashing against the land, I think.

[TomorrowPlusX]

It's great to see new screens of your engine. Very inspiring.

One thought about all games with water: where the water meets the ground. Is there anything you can do about that? Either by making the ground automatically take on texture modifications that make the ground "damp" (maybe just reducing the brightness of the textures that were just uncovered recently from the water), or even possibly make a little crashing against the wall?

The waves that appear when you intersect water with the object is similar to waves crashing against the land, I think.

Both of these matters are already being taken into consideration. I do darken the terrain under water -- I could just bump it up a bit. Waves against water edges, however, would be more complex. I do want to do it, however. It's really just a matter of defining edge patches and doing multipass with a frothy texture.

Right now, I'm takling bugs. The water doesn't render right with single-pass lighting... beats me why. I'll have some time spent in GL Profiler I suspect.

[Volte]

How long have you been working on this? What is your educational background?

[TomorrowPlusX]

How long have you been working on this? What is your educational background?

I've been working on *this* in particular since August... regarding my education, I'm 100% self taught, except for some Pascal and C classes in high school. I was an art major, and studied painting and printmaking -- I do graphic design as my day job.

[Volte]

You


Are


My


Hero.


Seriously. You inspire me so freaking much. Where do you work? How did you land the job?

[NicholasFrancis]

For foamy stuff at the surf, take a look at GooBall - I used a fairly decent technique there where I multitexture 3 copies of a foam texture & use the texture matrix to scale & offset.

For the blending stuff, do you use Register Combiners? They are a bitch to code, but run at full speed on old Geforces. You can do many effects using these (if you can be bothered, that is). Hint: A lot of the examples that come in the Cg manual show how to use them properly

[TomorrowPlusX]

Nicholas,

I've never heard of Register Combiners until now. It looks like something I ought to learn, however. Does it work on ATi cards?

That said, I made some minor improvements and bug fixes. But the biggest improvement was simply to make a better texture for the water. Instead of the classic caustics texture, I whipped up a perturbation texture in PS using the "ocean ripples" effect, and made a detail texture out of it. I render the texture twice using add-signed blending, on units 0 and 1 with different scaling and offsets across time, and a subtle spheremap on texture 2. Looks quite a bit better in my opinion.

http://zakariya.net/shamyl/Water/Screenshots-2005-12-12-01.png

http://zakariya.net/shamyl/Water/Screenshots-2005-12-12-08.png


Anyway, I'm reading the treatise on Register Combiners right now ( http://oss.sgi.com/projects/ogl-sample/registry/NV/register_combiners.txt )...

Speaking of Gooball -- that game has the *best* shader performance I've ever seen on my 5200. Is Cg just that fast? I mean, I wrote a basically on-liner grayscale shader a while back and it knocked my framerate from ~100 to ~10 on my card...

[Nick]

As soon as I saw that you posted in the main forum page, I knew I was going to be shown up :). That really looks cool. It's inspired me to take back up that old 3d terrain engine I was working on a while back and keep working the engine into, hopefully, something like you have (though it'll take me tons longer because I don't know half the stuff you do). Good job. Looks great. :D

[NicholasFrancis]

GooBall mainly used normal Texture combiners on the GF5200 (+ a few Reg. combiners) Better cards get an ARB_FP version of most shaders. Then there were some some ATI_TEXT_FRAGMENT_SHADERS for the R8500-R9200 users.

The fragment programs it used were generated by Cg, then hand-optimised in assembly. Note: you can also use Cg to generate register combiners. And, like ARB_FP, you should hand-optimize those.

We used a version of nvParse to get the register combiner things going. Getting it to run on a mac was a bit of a bitch, but only took a day or 2.

I would like to warn you against using spheremaps. Not sure about later cards, but I've seen quite a few drop polycount _heavily_ when using it. We have a builtin option for unity to generate a cubemap out of a spheremap. Then we apply the cubemap if the card supports it.

But yeah - really nice looking water there. Good hack.

[TomorrowPlusX]

GooBall mainly used normal Texture combiners on the GF5200 (+ a few Reg. combiners) Better cards get an ARB_FP version of most shaders. Then there were some some ATI_TEXT_FRAGMENT_SHADERS for the R8500-R9200 users.

The fragment programs it used were generated by Cg, then hand-optimised in assembly. Note: you can also use Cg to generate register combiners. And, like ARB_FP, you should hand-optimize those.

We used a version of nvParse to get the register combiner things going. Getting it to run on a mac was a bit of a bitch, but only took a day or 2.

I would like to warn you against using spheremaps. Not sure about later cards, but I've seen quite a few drop polycount _heavily_ when using it. We have a builtin option for unity to generate a cubemap out of a spheremap. Then we apply the cubemap if the card supports it.

But yeah - really nice looking water there. Good hack.

This sounds a little out of my league -- but I'll look into it anyway.

Regarding spheremaps -- well, that's interesting and good news, since I'm planning on migrating to cubemaps anyway.

Thanks for the kind words,

[NicholasFrancis]

Ok, from the top then (it really is not that bad)

1) Do normal combiners. We have a scripting language to set them up, but you don't need that.
2) If you want to use stuff like ARB_VERTEX/FRAGEMENT_PROGRAM, try writing it in Cg & telling it to generate the assembly stuff for you. (just use the cgc command line tool). I prefer working with the c-style shaders. When I find an effect I like, I then go in and hand-optimise that (if the object will be visible a lot). One of the nice things about C-style stuff is reusability. E.g. I'm using the same sine & cosine functions for making wavy trees in Intifada that were developed for gooball water.

3) If you want to get all the Radeon9200 (mac mini) guys up to speed, you should code it in ATI_TEXT_FRAGMENT_PROGRAM (or SHADER, can't remember). It's not that bad, but you need a machine to test it on.
4) If you want high performance from low-end geforces, you can do Register combiners - they are a major pain in the butt, and normally, I just can't be bothered.

---
This is my priority list for doing stuff. From least resistance to highest. There are a few tricks to get cgc to be nice, which I can go into if you care.

One way of doing these is to have effects; If you have an object that wants "SpecularLighting", you can try to see if you have a "SpecularLighting.arbfp" file & use that, or fall back to another level (or you select another shader). This is really nice, and scales quite well.

(Then there's the whole GLSL debate, which I don't really care to get into)

[TomorrowPlusX]

You know, reading over this material, I feel like it would be better just to use Unity ;)

My problem here is that I love the actual programming too much. My interests lay in the engine details, like the scenegraph, physics, etc. I wish I could just slap on pretty graphics on top. For example, I had *way* too much fun writing the tree generation algorithms, and the water subdivision for scenegraph management. Making the water and tree geometry was way more fun than writing the gl code to make it render.

[blobbo]

No no no! This engine looks terrific! You have such... graphic flair! Just post screenshots every week and we'll keep you going on compliments. :)

[Nick]

You know, reading over this material, I feel like it would be better just to use Unity ;)

My problem here is that I love the actual programming too much. My interests lay in the engine details, like the scenegraph, physics, etc. I wish I could just slap on pretty graphics on top. For example, I had *way* too much fun writing the tree generation algorithms, and the water subdivision for scenegraph management. Making the water and tree geometry was way more fun than writing the gl code to make it render.
Perhaps there is cheap/free rendering library you could encorporate into your engine that could handle all the pretty graphics so you could do the other stuff that you love. I really want to see how far you take this engine because it's already impressive and just keeps getting better. If I see anything that might help you, I'll let you know. :)

[TomorrowPlusX]

I've looked around and the most promising is Ogre3D, but it's a PITA to get to build right on OS X -- well, not the framework, but the demo apps barely work.

Plus, all the nice stuff Ogre gives you is too much for my wee 5200. Demos which run at 90fps on machines with good video cards render poorly and at 10fps on my powerbook.

Anyway, I consider myself "done" with the water system now. I've cleaned the code up, split it into a 3 pass render so I have better control over cubemap reflections and so on, plus I put in support for froth at the water boundaries. Finally, I added support for the water to be "frozen", where it becomes a solid geometry with collision and low friction. Aside from some minor tweaks I'm moving on...

EDIT New pics -- you can see a bit of a crappy "froth" texture at the edges, and the better mixing of cubemap reflection & the lerping to horizon-color based on the view angle -- and the final shot is underwater. I haven't ported my particle system code from my old engine so there's no bubbles or anything yet. There will be ;)

http://zakariya.net/shamyl/Water/Screenshots-2005-12-16-08.png

http://zakariya.net/shamyl/Water/Screenshots-2005-12-16-09.png

http://zakariya.net/shamyl/Water/Screenshots-2005-12-16-14.png

[NicholasFrancis]

That looks nice. I'm really impressed with how waterlike you can make the waves look by doing a signed add of two ocean ripple textures. Could I get you to share some insights on how you perturb the texture coords? I would like to include something like it in Unity as a low-end water shader

[Amorya]

Is there a downloadable demo for this? I had a glance through the thread and couldn't see one, but I may have missed it...

[AGhost]

This looks amazing? Do you have any dev tools, etc for building levels or is it just a scenery engine at this point. I would love to see a game made in this!

Ghost

P.S. A Downloadable build would be nice......

[TomorrowPlusX]

That looks nice. I'm really impressed with how waterlike you can make the waves look by doing a signed add of two ocean ripple textures. Could I get you to share some insights on how you perturb the texture coords? I would like to include something like it in Unity as a low-end water shader

Woo!

Well, it's actually really crude. Here's a 1000 foot view of how it's put together. I have a main class called "Water" which is a non-drawing entity, added to the world. The Water maintains the vertex mesh and manages the textures and overall state ( like the wave function ).

I then have 3 classes which draw the water. Water::Cell, which draws the solid geometry, Water::ReflectionCell which draws the cubemap ( as second pass ) and Water::EdgeCell which draws the foam at the edges. Each is a drawing GraphEntity, which means it's a first-class AABB bounded entity in the SceneGraphs.

I build them by creating "patches" ( which are just a struct with indices for the vertex arrays and so on ) from the water vertices and adding those patches to the cells, with jiggery pokery to create cells and add them to the scenegraph when needed ( based on the bounding box of the uniono f the cell's patches ) and to add patches to existing cells when a cell's already in the scenegraph.

This way I get my water drawing fully managed by the scenegraph but only one object, the "Water" instance, manages the memory.

The cells have an ordering override to the scenegraphs visibility set determination that causes them to be sorted and drawn in this order:

Water::Cells get drawn first
Water::EdgeCells get drawn second
Water::ReflectionCells get drawn last

My VisibilitySet class sorts objects such that objects which report requiring the same gl state to display are contiguous, so I can minimize state changes when drawing batches of similar objects. But their respective "drawing order" is still respected.

When any are drawn, the notify the Water object that it needs to update the wave function. It then calls updateGeometry on the cells, only the base class Water::Cell actualy modifies the geometry but it updates the vertex arrays for the subset of the water that is visible.

Regarding the texture coords, I actually just have two add-signed units with a pretty decent texture I drew in photoshop ( using Ocean Ripple filter on a perlin noise background, then duplicate the layer, invert it, gaussian blur it, than set opacity to 50% -- this gives me a good detail image with no low-frequency patterning -- which I then merged and clone-stamped until it wrapped nicely ).

The two texture units both draw the same image, texgenned along XY, with offset varrying along with the wave function.

The cubemap is just a vanilla cubemap, but I scale the vertex normals z-values by 0.5 before normalizing so I get a more visible rippling.

I'll post code soon, but it's not complicated. Really, it's just a matter of good textures and good choises of color. There's a lot going on with color to cause "reflection" of the sky color, a lot of code...

[TomorrowPlusX]

OK, I was (mostly) away from the internet for the holidays, but now I'm back. Here's the source for the water in case you're still interested, Nicholas.

http://zakariya.net/shamyl/Water/src/

The main class Water has several inner classes, which are defined in Water.h but are implemented in the files Water_innerclassname.cpp.

There's a fair amount of magic behind the scenes being done by my scenegraphs and that code isn't included, but will be when I'm ready. 99% of the important stuff for low-end display is in Water_Cell.cpp's setupState() and updateGeometry() methods.

[NicholasFrancis]

Nice Code... If only all of Unity was so easy to read ;-)

It's weird that you get such a good effect using only texgen... I'm impressed...

I know you didn't ask for any advice (and don't really seem to need it, either), but have you considered moving all glTexParameter calls into your Texture class? The thing is that these stick with the texture you're applying them to. Hence, you don't need to set them anew each time you want to use the texture, saving quite a few OpenGL calls....

Doing this in Unity allowed us to clear up a lot of code - at first, I was sceptical of not being able to change texParameter calls between uses of a texture, but when I thought of it, I could think of only pathological cases where I'd want to do that.

[TomorrowPlusX]

Nice Code... If only all of Unity was so easy to read ;-)


Thanks!


It's weird that you get such a good effect using only texgen... I'm impressed...


I appreciate the sentiment, but frankly, it still looks like ass compared to a proper system using shaders and real reflections. But, I just don't care that much since my powerbook has a 5200 and it simply doesn't have the horsepower.


I know you didn't ask for any advice (and don't really seem to need it, either), but have you considered moving all glTexParameter calls into your Texture class? The thing is that these stick with the texture you're applying them to. Hence, you don't need to set them anew each time you want to use the texture, saving quite a few OpenGL calls....

Doing this in Unity allowed us to clear up a lot of code - at first, I was sceptical of not being able to change texParameter calls between uses of a texture, but when I thought of it, I could think of only pathological cases where I'd want to do that.

Yeah, that's something that I've spent quite some time in consideration of. My issue is that when I try to clean it up, I often end of with weird artifacts where some tex unit is using spheremapping or something else weird because a previous display routine didn't clean up properly.

Obviously, I should clean up better, and I *do* try to. But since I'm a neophyte in GL, I've had better luck with completely excplicity setup and teardown, and I trust in my scenegraph to sort the display of objects to minimize the need to call setupState and teardownState. Which is to say, if in a scene I've got 20 Water::Cell instances to display, my scenegraph will display them contiguously, and only call Water::Cell::setupState and Water::Cell::teardownState once.

Fortunately, I've got a basic interface ( from which GraphEntity derives ) called SimpleSetDrawable which will automatically generate unique GL state identifiers for entities based on how they want to display ( based on a basic set of drawing features, like primary texture, detail texture, shading model, litghting, fogging, transparency, blend modes, etc etc etc ). So, I can have 100 trees using one set of bark and leaf textures, 100 more using other textures, 500 rocks using one texture and detail, and the scenegraph ( after determining the visible set ) will only have to run setupState and teardownState 3 times -- it's all automatic ( and fast, too, since the STL set algorithms rock ).

[TomorrowPlusX]

New trees!

I finally accepted that my foliage algorithm for the trees sucked, and I made a *much* better version this morning. I also, finally, made a proper texture for leaves.

http://zakariya.net/shamyl/Trees/Screenshots-2006-01-05-01.png
http://zakariya.net/shamyl/Trees/Screenshots-2006-01-05-03.png
http://zakariya.net/shamyl/Trees/Screenshots-2006-01-05-04.png

Finally beginning to actually look like a tree... :p

[funkboy]

Just lovely.

Has the poly count increased a lot with this algorithm? Seems like a lot more geometry on the tree, but maybe not.

[TomorrowPlusX]

It has -- I went from a triangular cross-section to octagonal. The number of leaves is up a little, but not too much. A well populated tree has, perhaps, 25 to 50% more leaves than before.

I'm planning on having the trees store a low-poly variant ( generated off the same seed, but using triangular cross section like before ) for drawing at a distance.

[skyhawk]

*cries and paws at the trees*

so beautiful

[NicholasFrancis]

Looks nice - a few suggestions:
Precalculate world vertex lighting. Since the world lighting is not going to change, you can get more polies in if you precalc the lights. Not a huge benefit in itself, but does lend the way to this:

Implement self-shadowing. For each vertex, cast a ray towards the sun. Make the branch block the ray and each leaf reduce the lighting by a certain percentage. While seemingly minor, leaf self-shadowing makes a huge difference to the percieved depth of the tree.

Have you considered billboarding the trees. The have a great trick in Far Cry: You're not allowed to rotate the trees. This means that all trees of a given type are seen from the same direction (as they are very far away). This works really well and keeps the billboard numbers down. Also, allowing scaling of trees will give you a lot of variety without having to store the meshes. Scaling doesn't affect billboarding.

You could still rotate trees, though.. AFAICS from their editor, they split trees into 2 types: Clumps of trees (for forests) or smaller (let's call them "key" trees). Key Trees were just normal meshes.

[blobbo]

Just gorgeous. More screenshots, more often!

*can't wait for gameplay*

[TomorrowPlusX]

Looks nice - a few suggestions:
Precalculate world vertex lighting. Since the world lighting is not going to change, you can get more polies in if you precalc the lights. Not a huge benefit in itself, but does lend the way to this:

Implement self-shadowing. For each vertex, cast a ray towards the sun. Make the branch block the ray and each leaf reduce the lighting by a certain percentage. While seemingly minor, leaf self-shadowing makes a huge difference to the percieved depth of the tree.


Trouble is this -- the tree's are "cloneable" in that I can have 500 trees share one geometry, collision mesh, and foliage instance. Meaning I have to have dynamic lighting in the foliage. I will probably, however, lrp the leaf color to ambient based on its depth in the tree.


Have you considered billboarding the trees. The have a great trick in Far Cry: You're not allowed to rotate the trees. This means that all trees of a given type are seen from the same direction (as they are very far away). This works really well and keeps the billboard numbers down. Also, allowing scaling of trees will give you a lot of variety without having to store the meshes. Scaling doesn't affect billboarding.

You could still rotate trees, though.. AFAICS from their editor, they split trees into 2 types: Clumps of trees (for forests) or smaller (let's call them "key" trees). Key Trees were just normal meshes.

I'm considering it, actually. Performance is hit real bad when I've got a lot of trees, even though the scenegraph culls most of them and draws them sans texturing or lighting if they're beyond the fog plane.

[ThemsAllTook]

Looking really good from the trunk up, but I think it would add a lot if you would do something to the ground around the trunk to make it more believable. A few roots visible here and there, transition from grass to dirt closer to the trunk, etc.

[DoG]

Awesome trees. I like the whole GUI, can you elaborate a bit on how the interface is implemented?

Two years ago, when I was doing my BSc, a group doing computer graphics in the same lab where I was working were making large forests with billboarding. I remember they had whole forests running in real-time.

They came up with stuff like this:
http://www.iit.bme.hu/~szirmay/tree2.pdf

[TomorrowPlusX]

That imposter stuff is *awesome*. I'm going to have to scope it out.

Regarding the GUI, it's complicated. I have done several gl guis where I sort of hacked them together and I got pissed off that it was so messy and not re-usable. So I sat down and identified the minumum set of functionality that would be good enough, and would be scalable, and then spent a month building it. It does layout management, event-queues for input handling, automatic sizing based on font metrics, nested views, scrollbars/panes, etc.

[funkboy]

Looking really good from the trunk up, but I think it would add a lot if you would do something to the ground around the trunk to make it more believable. A few roots visible here and there, transition from grass to dirt closer to the trunk, etc.

With this comment, and my earlier one about the ground/water interface (the transition from ground to water), I think the transitions are the place least looked at in computer graphics. If there was some upheaval of dirt around the tree, roots, etc. ... it makes it look like it came from underneath.

So maybe I can make a little rule: for really spectacular geography, pay attention to the transitions.

(of course, this is only applicable once you get to the level of TomorrowPlusX already is his an engine)

[DoG]

…
Regarding the GUI, it's complicated. I have done several gl guis where I sort of hacked them together and I got pissed off that it was so messy and not re-usable. So I sat down and identified the minumum set of functionality that would be good enough, and would be scalable, and then spent a month building it. It does layout management, event-queues for input handling, automatic sizing based on font metrics, nested views, scrollbars/panes, etc.

This is a little bit OT for trees, but what the heck: I was asking because I did write a GUI with window manager and whatnot in OpenGL/C++, in the past. It was less than stellar, to say the least. Yours beats it up and poops on it. Still, I think the idea of rolling your own GUI has a lot of potential, especially if you develop cross-platform.

Ok, I also have 2 specific questions:
1) Events: do you let your events propagate from subview to superview, or the other way around?
2) Fonts: What do you do for drawing glyphs, and text layout?

[TomorrowPlusX]

With this comment, and my earlier one about the ground/water interface (the transition from ground to water), I think the transitions are the place least looked at in computer graphics. If there was some upheaval of dirt around the tree, roots, etc. ... it makes it look like it came from underneath.

So maybe I can make a little rule: for really spectacular geography, pay attention to the transitions.

(of course, this is only applicable once you get to the level of TomorrowPlusX already is his an engine)

I would love to pursue this -- since I'm in 100% agreement -- but this is a complex topic. Worth thinking about, but a complex topic. I'd probably have to identify the polys of the terrain which intersect the trees bases and have a separate pass render a disruption.

Fortunately, I already have the code from my last game for applying scorch marks. All I'd have to do is apply the same code but use a different texture.

Thinking about this a little more, I bet I could have each tree create a mostly flattened sphere at its origin ( on the ground ) with rough perturbation and a nice dirt/rock texture. This shere would be placed at the bottom of the tree and be rotated to match the normal of the surface the tree is on. This could be really simple, actually. It might not necessarily even have to be randomly generated. I could just model a few of these in wings, texture them, and randomly select one for each tree. Obviously, I'd only display it when the tree's close...

[TomorrowPlusX]

This is a little bit OT for trees, but what the heck: I was asking because I did write a GUI with window manager and whatnot in OpenGL/C++, in the past. It was less than stellar, to say the least. Yours beats it up and poops on it. Still, I think the idea of rolling your own GUI has a lot of potential, especially if you develop cross-platform.


Thanks! But it might not be quite so good it poops on yours. Maybe it farts in yours' general direction. But no pooping, I'm certain.


Ok, I also have 2 specific questions:
1) Events: do you let your events propagate from subview to superview, or the other way around?


Actually, I have two kinds of event. Events like mouse movement, clicks, resizing, painting -- e.g. window system type events -- propagate from the window root recursively to leaf children. These are processed synchronously.

However, events like what happens when you click a button, or drag a slider, or select an option in a combobox -- those are "Notifications", and they're enqueued with the app's "notification pump". Each "NotificationSource" ( e.g. a button or whatnot ) has a list of listeners ( like Java ) and those listeners are set as targets for the notifications to be sent to. The notification pump processes the FIFO queue of notifications and lets the targets act as they will based on the notifications they receive.

The important part is that enqueuing a Notification doesn't result in its immediate execution -- instead it will be executed at the end of the current timestep. So if you have the hypothetical situation where a window is closed and deleted by clicking "OK" or "Cancel", this will work safely, since the window's button's posting of the notification returns immediately, and the listener's call to delete the window happens later, after control has returned from the window's button's posting of the notification.


2) Fonts: What do you do for drawing glyphs, and text layout?

I use FTGL, but I'm thinking of migrating to a glyph matrix, since FTGL's font metrics are *invariably* wrong, specifically the ascender and descender, making vertical centering of text in a button a black art based only on luck and frustrating "magic" numbers. For actual text layout I wrote my own line-run algorithm for doing line wrapping automatically. It's not as fast as ATSUI, but it's good enough, and only expensive when dimensions change, since it caches the layout.

[staigerman]

not sure if I postred on this thread ye, if you're still looking for a tree/plant generator, Carrara Studio 3 and higher comes to (my) mind.

http://www.thebest3d.com/carrara/plants

the old version 3 of Carrara Studio installs and works on OS 8, 9 and 10