Plan for Ben Garney
by Kyle Carter · 06/12/2004 (11:51 pm) · 37 comments
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.
#22
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...)
06/13/2004 (3:38 pm)
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...)
#23
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...
06/13/2004 (5:06 pm)
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...
#25
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?
06/14/2004 (10:55 am)
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?
#26
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.
06/14/2004 (1:16 pm)
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.
#27
06/14/2004 (1:26 pm)
Woah! I wonder how those people feel that bought SpeedTreeRT now!? 
#28
(I'll be using this, because I don't nessisarily need everything SpeedTreeRT has to offer :-)
06/14/2004 (1:31 pm)
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 :-)
#30
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.
06/14/2004 (2:36 pm)
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.
#31
@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.
06/14/2004 (2:56 pm)
@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.
#33
- Peter
06/14/2004 (7:09 pm)
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
#34
06/14/2004 (8:06 pm)
@Peter: Truly. Though I was under the impression that SpeedTree was at its best when dealing with organic structures like trees, ferns, etc.
#35
- Peter
06/15/2004 (4:10 am)
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
#36
[HOW]EdM
06/16/2004 (10:27 am)
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
#37
06/16/2004 (10:39 am)
TSLastDetail is basically an imposter rendering. As I work with the forest code my nomenclature is gradually changing. :) 
Torque Owner Stefan Lundmark