Previous Blog Next Blog
Prev/Next Blog
by date

Plan for Ben Garney

Plan for Ben Garney
Name:Ben Garney
Date Posted:Jun 13, 2004
Rating:4.8 out of 5
Public:YES
Comments:YES
RSS Feed:GarageGames Blog feedor Subscribe with .
Profile Page:View profile page for Ben Garney

Blog post
In my elusive spare time, I'm currently working with Robert Blanchet and Wes Beary on a forest code pack. The idea is to code up a fast forest renderer that people can use as a quick, cheap alternative to more expensive and comprehensive tree rendering solutions.

Wes chipped in some cheesy tree placeholder art (done to the special requirements of the renderer), and Robert and I hammered on the task of writing the renderer. Clark, ever the 3space wizard, gave us some valuable guidance.

And here are some screenshots, from my pathetic GeForce2 powered laptop:








The forest pictured contained 29921 trees, of which about 500 were actually being rendered at any given time. Before the forest, Torque ran at about 70fps. After the forest it averaged about 45fps. My CPU is 1.8Ghz.

Two geometry detail levels per tree (we had two types of trees) and one automatically generated billboard detail level were used. If you look very closely, you can see some nasty glitches in the detail selection code, as well as some overlapping trees - these are both known issues and we're working on fixing them. The forest code is fully networkable. You can define clearings as well as what trees are placed where and with what probability. There are a lot of options to tweak forest LOD. Things like rocks and ground cover can also be rendered using the forest code.

Anyway, I'll probably post another .plan when we have better art and get some of the more heinous rendering and performance flaws fixed up.

Disclaimer: This is work I am undertaking as a private citizen, not as a GarageGames employee. By posting this plan, I am in no way implying that GG is involved in the development of this product, nor am I implying that GG condones my development of this technology.

Recent Blog Posts
List:12/19/08 - Blast From The Past: Blitz3D Models in Torque
12/04/08 - Blockland Physics
09/22/08 - Austin GDC Talks: Robust Efficient Networking and Flash MMOs
05/30/08 - Next Big Thing
02/12/08 - Come See Me At GDC 2008!
10/27/07 - TGEForest Free Release
10/13/07 - Polysoup Free (And IGC)
01/26/07 - Speaking and Running Into Walls (Collision Fix)

Submit ResourceSubmit your own resources!

Davis Ray Sickmon, Jr   (Jun 13, 2004 at 07:05 GMT)
Nice - very nice. This will be fun when it's released :-)

Phil Carlisle   (Jun 13, 2004 at 07:31 GMT)
Looks funky Ben. What do the trees look like from above? I would imagine the billboard show up quite a lot there?

Anyway, looks funky.

What about the pack? get on with it!!!

Ben Garney   (Jun 13, 2004 at 07:37 GMT)
Actually, it uses TSLastDetail so if you look straight down from high above you see.... the tops of trees.

;)

mm   (Jun 13, 2004 at 07:41 GMT)
Ben, this is a really impressive project you and the others are working on, with so many people asking for a resource on how to integrate "more expensive and comprehensive tree rendering solutions" this will be very useful. Can't wait to check it out.

Matt

Robert Blanchet Jr.   (Jun 13, 2004 at 07:48 GMT)
Since my machine is a little beefier then Ben's I ran my settings a little more aggresively. There are over 12k trees being rendered in the below shots.




Dylan Sale   (Jun 13, 2004 at 08:32 GMT)
Those are some small trees... But I love it. Its like uber fxFoliage :D

Greg Ellwood   (Jun 13, 2004 at 08:41 GMT)
Guess I won't be needing SpeedTree after all ;)

Great job guys!

-Greg.

Thijs Sloesen   (Jun 13, 2004 at 10:07 GMT)
Awesome guys! Can't wait to try this :)

Jorgen Ewelonn   (Jun 13, 2004 at 12:25 GMT)
Mmmm, Ben, I am a layman when it comes to programming but have been tossing around some ideas when it comes to real-time forests.
The thing I've been thinking, if you auto-magically splice the tree in 4 and render the side(s) closest to (in line of) the viewer (player) in high detail and all other sides at low detail (or not at all) within a given radius and a certain field of view (something lower than the regular FOV, say 60), the trees that lies outside that radius and the detail-FOV could be plain billboard.
It's just a tought, I have been meaning to look into this but it is loow on my list. Would this be a stupid approach ?

Stefan Lundmark   (Jun 13, 2004 at 12:35 GMT)
@Ben & Robert: Looks quite cool! What fps drop did you notice? Will this be integrated into TSE, and how will it be released?

@Jorgen: AUTOMATICALLY, not magicely :P

Banshee   (Jun 13, 2004 at 13:16 GMT)
Do you know if you will release this for TGE as well, don't forget about us guys :(

Paul Dana   (Jun 13, 2004 at 13:27 GMT)
@stefan: i think the autoMAGICally was an intentially jest. Joke. Yuk yuk.

Jorgen Ewelonn   (Jun 13, 2004 at 13:29 GMT)
@Stefan & Paul: well, to get any of my ideas to work you'd probably need some magic :)

Michael Cozzolino   (Jun 13, 2004 at 15:46 GMT)
Sweet. Everyday I log in there is something else kickass being worked on.

Thomas \"Man of Ice\" Lund   (Jun 13, 2004 at 15:48 GMT)
So Ben, Robert and Wes

Could you explain how your code differs from fxShapeReplicator? I know its different, just wondered what kind of automated stuff you got in there that is different than the simple shape replicator.

Also are there any requirements on the models themselves to work with your code?

Ben Garney   (Jun 13, 2004 at 16:10 GMT)
Brief response before I head out for today:

This is on TGE. TSE doesn't run on my laptop.

This does optimized culling and rendering, unlike fxShapeReplicator, which just stuffs a lot of StaticShapes into the scenegraph. It's a lot more like fxFoliage, except for arbitrary models.

The models have 2 geometry detail levels and a billboard level. This can be changed but so far it looks good so we haven't bothered.

I should point out that Robert's screenshots ran at about 4fps. ;) The ones in my .plan do run in realtime: 40-50fps. It's all a question of rendering 12000 trees or not.

Hope that answers your questions!

David Grace   (Jun 13, 2004 at 17:39 GMT)
Woo, way to go Ben! In fact, you beat me to it! I was working on a very similiar thing, but put it aside when I was having some issues with LOD selection code.

I had the exact same thought; A modified fxShapeReplicator to work something like fxFoilage, with a culling region and batched rendering of DTS objects. (With a user-selectable override for LOD selection, so they could have more sparse or lush forests at whim.)

A sort of budget version of something like SpeedTreeRT, in effect.

Glad to see I'm not the only one wanting something like this! Great job!

Ted Southard   (Jun 13, 2004 at 18:01 GMT)   Resource Rating: 5
This is completely awesome :) I've been wondering about a solution like this for a while, since I've been having to do multiple fxShapeReplicators(and the optimisations would be very welcome too). You guys rock!

Timothy Aste   (Jun 13, 2004 at 18:30 GMT)
Whoa

Pascal Bos   (Jun 13, 2004 at 19:29 GMT)
Nice work guy's, we can not do without a good looking forrest. If you need a better tree model to work with mail me (pascal@nedcore.com) i might have something you can use.

Keep it up it looks great

Stefan Lundmark   (Jun 13, 2004 at 20:27 GMT)
This could probably be used for non-trees (like bushes) too, very cool!

David Montgomery-Blake   (Jun 13, 2004 at 22:38 GMT)
Wow. I love it. I'd been somewhat worrying about the forest level in my shooter (even though you never see THAT much of the forest from the top-down perspective). Seeing this makes me worry a lot less. Right now I'm more worried about creating models than I am how many trees I'll be able to see on the level, but it doesn't hurt to look ahead!

Isn't the cabin in the first picture being eaten by a Christmas Tree Monster?

(I'd been waiting for a way to weave Beyond Zork into a post for some time. Now if I can just find one where I can weave Nord and Bert Couldn't Make Heads Nor Tails Of It...)

Ben Garney   (Jun 14, 2004 at 00:06 GMT)
Yes, you can use this for foliage and bushes and rocks and all sorts of neat stuff.

There are still some placement tricks to be implemented. Slope and interior/water checking are two big ones, in terms of added functionality. This would prevent the tree-in-building issue you spotted. :)

For that sort of a shooter situation, you could even optimize the culling code to do a rectangular area instead of a triangular area...

Jeff Tunnell   (Jun 14, 2004 at 05:09 GMT)
I'm so damn proud of these guys. *sniff*

Way to go.

-Jeff

Luigi Rosso   (Jun 14, 2004 at 17:55 GMT)
This sounds like an excellent idea!

How're you going to handle transparency sorting? Each replicator would need to sort it's own data and then do some sort of merge sort with the other replicators right? But how does that work with the rest of the scene render images?

Ben Garney   (Jun 14, 2004 at 20:16 GMT)
This isn't a replicator solution. There are some transparency-related sorting issues we're going to have to deal with - it will be interesting to see how complex that part of the problem gets. A lot of it depends on the world you're working on. A world with lots of transparent buildings is going to be much more difficult to render properly. My baseline is to get the starter.fps mission working properly.

It's possible we will have to extend the scenegraph a bit to deal with complex tree/transparency situations, but I'd prefer not to.

Matthew Spindle Harris   (Jun 14, 2004 at 20:26 GMT)
Woah! I wonder how those people feel that bought SpeedTreeRT now!?

Davis Ray Sickmon, Jr   (Jun 14, 2004 at 20:31 GMT)
Probably pretty good, because if they actually went out and bought SpeedTreeRT, then they needed for game development now. This isn't released, there's still issues, and it's not been used in a game yet to sort out all the potential problems. (Disclosure: I'm NOT a SpeedTree licensee.) Also, this doesn't nessiarily have all the features of SpeedTreeRT. When this comes out, there's still a decision that has to be made, and not nessiarily just about money :-)

(I'll be using this, because I don't nessisarily need everything SpeedTreeRT has to offer :-)

Lee Nau   (Jun 14, 2004 at 20:38 GMT)
Cool stuff.

David Grace   (Jun 14, 2004 at 21:36 GMT)
I agree with Davis. SpeedtreeRT is more than just a special-case LOD selector for a bunch of objects. From what I gather on how it works, it generates its own set of trees and then in realtime adjusts the parameters. (Adds more leaf nodes and so on.) Sure, you can simulate this by making your own tree models and hand-tweaking all of these LOD settings, but STRT saves you a lot of work. Plus, since it's all runtime-modifiable options, it's something you can tweak ingame for your particular system. Instead of just making a few models and carefully adjusting polycounts so they don't overload your target system...

I can see the transparency issue being a concern. You're going to want to use this mostly for things like trees and such, which will have a large number of transparent polys. If you just inject them into the scenegraph as normal transparent polys, you're losing some of the optimizations of batching. Hmmm. I haven't dug around in that part of the code yet so I'm not too clear how it works.

Ben Garney   (Jun 14, 2004 at 21:56 GMT)
@Davis: Good point. Don't pick on the SpeedTree guys - they after all have a working product which they have paid a fair chunk of cash for, while we have something that's unfinished.

@David: This addresses a slightly different niche from SpeedTree, actually. You can do rocks with it - basically anything. SpeedTree is rather more specialized. Obviously, given the choice you probably want SpeedTree, but my hope is that people will be willing to save many thousands of dollars and deal with a shallower featureset.

It's sort of like using MilkShape instead of Maya.

Adam deGrandis   (Jun 15, 2004 at 00:33 GMT)
How terribly exciting. :)

Nice work, guys.

Peter Kojesta   (Jun 15, 2004 at 02:09 GMT)
Actually, You can do rocks, chickens, and just about whatever else you want with Speedtree. its about 10x more robust then anyone is giving it credit for.

- Peter

Ben Garney   (Jun 15, 2004 at 03:06 GMT)
@Peter: Truly. Though I was under the impression that SpeedTree was at its best when dealing with organic structures like trees, ferns, etc.

Peter Kojesta   (Jun 15, 2004 at 11:10 GMT)
It has a lot of built in procedural tools for trees and the like, but its quite elegant in dealing with many other forms of objects. Either way, I'm glad you're making this Ben, cheers to you.

- Peter

Edward F. Maurina III   (Jun 16, 2004 at 17:27 GMT)
So, Ben you're talking about pseudo-imposters? If not, since you've already gone the step to make a billboard level, you might consider doing a full LOD triggered imposter. Either way, best of luck, looking forward to more updates.
[HOW]EdM

Ben Garney   (Jun 16, 2004 at 17:39 GMT)
TSLastDetail is basically an imposter rendering. As I work with the forest code my nomenclature is gradually changing. :)

You must be a member and be logged in to either append comments or rate this resource.