Joshua, I'm also very interested in this. I'm working on a forest visualization project at Oregon State University, and had considered SpeedtreeRT as well.
I have a hunch where you would integrate it, or how. Take a look at DetailObjectSystem.cpp - which handles the detail stuff (fading out grass props, etc.) Basically what it does is something like this... 1) On map load, it creates a list of all detail props in the map as defined in the BSP 2) Maintains a sub-list of potentially visible detail props as player moves around from leaf to leaf 3) Renders that list each frame, applying fade over distance What I think would be the correct method of integration is to use this code base as your model, however assume that you will not be loading the trees from the bsp. For one thing, the game limits the number of props in the bsp. I've been thinking of writing my own tree system using this as the framework, but instead of loading the tree placements from bsp, they would be loaded from a separate file, or possibly dynamically generated as the player moves about. Basically if you could calculate terrain surface (assume it's all displacement surfaces) and also calculate tree types and density (based on material used on the displacement), you could dynamically populate that draw list of detail props. You could also do some pretty effective LOD management here as well. For example, you could draw trees as simple Z locked sprites when they are distant, and then draw actual models when closer up. Also, you could modify the maximum visible distance based on the tree density. In a thick forest, you don't need to draw trees very far. In a thin one, you need to draw them far away. You also can take the angle between the tree's Z axis and the player. If the angle is very small (ie, the player is looking down on the tree) then you can potentially render a completely different (and possibly simpler) sprite. Another idea I had was to create a new shader specifically for terrain. Suppose you had a brown/dirt forest floor, with trees. If you are under the trees, you want to see the brown forest floor. If you are above them, you want to see trees and no forest floor (all green). Now suppose you had a distant tree covered hill visible in the engine. If you don't render the trees onto it, you'll just get a brown hill, which won't work at all. What you need is like a blend texture, where the farther away you get, the more the underlying texture comes out. SO you could have a brown dirt "top" texture, and a green leafy "bottom" texture. The farther you move away from the ground, the more the green comes out - until eventually it's all just green leafy cover as if you're looking at just trees. If nothing more comes of the email in this, list, let's talk offline on this. Very interested in sharing tree rendering insights if you're interested. Tim Quoting Joshua Alejandro Jacobo <[EMAIL PROTECTED]>: > We are currently looking to use SpeedtreeRT to generate real-time trees > in our mod, as well as larger project down the line, but we are trying > to determine if it is possible to integrate the code into the SDK, the > people at IDV not offering as much documentation as we would like > (except for an outrageous monthly fee). Here is how IDV describes their > program: > > /Interactive Data Visualizations (IDV) SpeedTreeRT is a C++ Application > Programmers Interface (API) designed to provide access to SpeedTree > data for interactive, real-time applications. SpeedTreeRT parses the > .spt files created with SpeedTreeCAD (a stand-alone Microsoft Windows® > application) and delivers all tree data to the calling application via a > well organized, easy to use API. Because SpeedTreeRT is independent of > the rendering system, it is applicable to almost any situation where > high quality, three dimensional trees must be rendered in real-time. > SpeedTreeRT ships with a comprehensive SDK that contains examples of how > to render SpeedTrees in some of the more common rendering environments, > such as DirectX, OpenGL, and the Gamebryo game engine. > > /and later: > > /The final critical advantage offered by SpeedTreeRT is optimal data > organization for popular rendering systems. Organizing the data so that > it seamlessly fits into your rendering method (e.g., OpenGL® vertex > arrays, DirectX vertex buffers, etc.) means that SpeedTrees will render > with maximum performance in your application. > > /And in response to a question: > / > //Q. What graphics API does SpeedTreeRT use? > A. SpeedTreeRT doesn't depend directly on any specific graphics API; > it's a numerical engine. However, SpeedTreeRT does facilitate the use of > some graphics APIs by defining geometry with pointers to vertex buffer > formats that can be used directly with API calls. > SpeedTreeRT does not make use of any system-specific calls. It was > written using C++ and the STL library. > > /While browsing through their SDK, I ran into this in the documentation > referring the the work the sample application (Source) would be doing: > > /Sample Applications: > The application handles all basic functions for a particular engine, > such as the creation of a window, user interaction, handling messages, > etc... > The sample application also handles creation of the scene as a whole. > This involves the placing of trees and other objects into the scene. > When needed, the sample application makes calls to the current SpeedTree > wrapper class to access update, rendering, and state management > functions of the SpeedTrees > > /Our question isn't whether the physics and rendering engine are > included in the Source SDK because we know that they are not, but > rather: would implementing a system such as this be possible, and would > access to any API of the Source Engine be possible in any way? > > I appreciate your feedback ahead of time. > > -Joshua Jacobo > Creative Director > http://www.realmsofvalhallon.com > / > / > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
