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: | or 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.
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 your own resources!| Davis Ray Sickmon, Jr (Jun 13, 2004 at 07:05 GMT) |
| Phil Carlisle (Jun 13, 2004 at 07:31 GMT) |
Anyway, looks funky.
What about the pack? get on with it!!!
| Ben Garney (Jun 13, 2004 at 07:37 GMT) |
;)
| mm (Jun 13, 2004 at 07:41 GMT) |
Matt
| Robert Blanchet Jr. (Jun 13, 2004 at 07:48 GMT) |



| Dylan Sale (Jun 13, 2004 at 08:32 GMT) |
| Greg Ellwood (Jun 13, 2004 at 08:41 GMT) |
Great job guys!
-Greg.
| Thijs Sloesen (Jun 13, 2004 at 10:07 GMT) |
| Jorgen Ewelonn (Jun 13, 2004 at 12:25 GMT) |
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) |
@Jorgen: AUTOMATICALLY, not magicely :P
| Banshee (Jun 13, 2004 at 13:16 GMT) |
| Paul Dana (Jun 13, 2004 at 13:27 GMT) |
| Jorgen Ewelonn (Jun 13, 2004 at 13:29 GMT) |
| Michael Cozzolino (Jun 13, 2004 at 15:46 GMT) |
| Thomas \"Man of Ice\" Lund (Jun 13, 2004 at 15:48 GMT) |
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) |
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) |
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 |
| Timothy Aste (Jun 13, 2004 at 18:30 GMT) |
| Pascal Bos (Jun 13, 2004 at 19:29 GMT) |
Keep it up it looks great
| Stefan Lundmark (Jun 13, 2004 at 20:27 GMT) |
| David Montgomery-Blake (Jun 13, 2004 at 22:38 GMT) |
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) |
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) |
Way to go.
-Jeff
| Luigi Rosso (Jun 14, 2004 at 17:55 GMT) |
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) |
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) |
| Davis Ray Sickmon, Jr (Jun 14, 2004 at 20:31 GMT) |
(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) |
| David Grace (Jun 14, 2004 at 21:36 GMT) |
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) |
@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) |
Nice work, guys.
| Peter Kojesta (Jun 15, 2004 at 02:09 GMT) |
- Peter
| Ben Garney (Jun 15, 2004 at 03:06 GMT) |
| Peter Kojesta (Jun 15, 2004 at 11:10 GMT) |
- Peter
| Edward F. Maurina III (Jun 16, 2004 at 17:27 GMT) |
[HOW]EdM
| Ben Garney (Jun 16, 2004 at 17:39 GMT) |
You must be a member and be logged in to either append comments or rate this resource.



4.8 out of 5


