I've got some pictures online at http://oregonstate.edu/~holtt/forestry/ that show some of what I've got going now with trees. That's terrain around Tillamook in Oregon - extremely steep and forested stuff. 16000x16000 displacement mesh ground covering approximately 1.28km x 1.28km. Player is at 1/4 scale to increase the appearance of the size of the map.
Quoting Ben Davison <[EMAIL PROTECTED]>: > -- > [ 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 > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
