-- [ Picked text/plain from multipart/alternative ] A bit OT: But did you advertise this mod on hl2world, because I remember seeing something like this and being amazed.
On 8/9/05, Tim Holt <[EMAIL PROTECTED]> wrote: > > 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 Visualization's (IDV) SpeedTreeRT is a C++ Application > > Programmer's 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(r) > > 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(r) 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 > > -- - Ben Davison - http://www.shadow-phoenix.com -- _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
