Has anyone solved the

[Guest christian]

>For every >pair of intersecting triangles, the line of intersection has >to be calculated and the two original triangles >clipped/divided into smaller ones. Why? Sorry I haven't made any trees in FS yet, so maybe I'm missing something. In principle you can cross 2 rectangles (you can even do 2 triangles, but it's painful to get the correct intersection). This is how it's done in normal 3d viz apps. So you get away with 2/4 triangles. What's the problem in FS?> The >single plane rotating towards the viewer has many >theoretical advantages, including the fact that it reduces >to just two triangles, Here's a trick I learned when reading someones PhD thesis on rendering vegetation: You can render a tree bitmap onto just one triangle! You obviously have a lot of 'black' in your bitmap then, and FS2002 has to draw 'bigger' trees. The author of the PhD thesis seemed to suggest that although the bitmaps are bigger, it's faster due to the reduced polygon count. Worth an experiment I think>but its drawback is the considerable >overhead of the rotation mechanism. If we could use 'imposters', that problem wouldn't be as significant anymore. Imposters are billboards that get rendered into static sprites. What happens is that FS2002 wouldn't need to rotate the image every frame. If we have a look at the trees far away. They barely rotate, so they might as well be treated as being static. As we get closer, they slowly start to rotate towards us faster and faster and need to be updated more frequently. Since most of the trees are far away though, we would gain significant speed using imposters...>Another way of modelling trees in future might be through >the octtree-based volumetric texture format implemented in >DirectX, but whether this will be suitable for >realistic-looking trees I wouldn't yet know (its obvious use >is for clouds and, perhaps, water). Can't comment too much. One of the main problems with 3D tetures still is that they are huge. I haven't seen them get used much yet...Christian

[akriesman 0]

I'll check it out.Allen

[Guest GerrishGray]

Hidden surface removal is normally done in FS (and many other graphic systems) by the simple 'painters algorithm'. Every potentially visible surface is actually drawn in its entirety, but the surfaces closer to the viewpoint are drawn after those further away so that they 'overpaint' the hidden surfaces, or the hidden parts thereof. This doesn't work when two surfaces actually intersect, because there is mutual obscuration of different parts of each surface by the other. The only way to get the painters algorithm to work is then to calculate the line of intersection of the two surfaces trigonometrically and divide the surfaces into smaller triangles along the line of intersection. This creates a big overhead on the display system if it is left to runtime, so it is better to do it at design time. I expect you will find that the documentation of 3DS mentions this and recommends that a 'weld' is done whenever surfaces / parts intersect. The 'weld' process does the intersection calculation.Your PhD student's thesis observing that any flat surface, such as the monoplane tree model, can be geometrically rendered as a single containing triangle will often not work out well in practice, I'm afraid - or certainly not with the FS engine. Much more time and memory space is needed to load the larger texture (the alternative is a loss of resolution) and then to render it using the painters algorithm. The larger transparent areas are a particular load on the rendering process. As we all know from hard experience, transparency is very convenient for rendering complex objects like trees, but has often lead to problems and always slows frame rates in FS because of the need to check every individual pixel for transparency rather than just 'blit' the entire bitmap into the screen buffer. From my experiences of testing various tree models in FS, I am fairly sure that the larger, single triangle, model will tend to be slower than a 2-triangle, 4-sided shape. The latter allows better resolution of the visible tree, or whatever, on the same size rectangular bitmap, and a more closely clipped model to render.So the rotating monoplane model is better off, in most cases, with two triangles rather than one (although some tree shapes obviously do lend themselves to a single triangle).As regards the static cruciform model, a 'single triangle' version needs 4 triangles surely if one is going to allow 3D viewing from any direction, whilst the rectangular or rhomboidal versions need 8? The FS engine has no direct provision for double-sided surfaces (even if DirectX does?) and both sides must be included with separate triangles in the triangle list. These numbers are doubled once one has made allowance for the intersection problem created by the cruciform model. So the cruciform model normally produces 16 triangles, as compared with just 2 for the rotating monoplane.I suspect, however, that you are right in thinking that the overhead of the rotation may still be greater than that of the extra triangles, now that we are using the DirectX-friendly fp rendering commands. But the rotating model will always score on realism because of the shading problem inherent in the cruciform version (which is where this thread started!).The scheme I have in mind for the next generation of FS trees is indeed based on a highly simplified implementation of imposters to try to optimise between the conflicting factors ...!CheersGerrish

[Guest christian]

Got you now. I see you seem to have some experience with trees ;)Back to the original question. I suspect the FS2002 is usig real lighting, rather than calculating lighting using lightmaps, etc. So what we really want to do is a 'glDisable( GL_LIGHTING )' draw the trees and then switch the light on again (of course in DirectX rather than opengl, but I don't know directx). I don't know if FS is varying the brightness of the sun to simulate nights, so switching off the lighting wouldn't help then, unless we can modulate the texture with the light intensity. Wouldn't have a clue how to do that with bgl commands though. Maybe make the texture bright, but then (somehow) modulate the texture brightness with the time of day? The very strange thing when I was playing with the reflective textures on the buildings, it seems as if there is the directional sun light, but also an ambient light component. This is all odd. I wonder if FS will eventually use per-pixel lighting, since we only have one light source, this could be done with not much of a framerate hit on cards with 4 texture units (GF3+)...Cheers, Christian

[Guest GerrishGray]

Hi ChristianActually, I was very interested in techniques for computerised rendering of 3D scenes about 30 years ago, when all these techniques were first being developed/investigated ... But we never got very far on the computers we were using in my lab at the time and, anyway, I soon moved on to other things. My interest in this aspect of computer science lay dormant until rekindled in recent years by FS :-)I think that the lighting techniques used by the current version of FS use a very simplified form of ray-tracing without any ray reflection - i.e. the intensity of the lighting on a surface is calculated from the position of the sun, intensity based on time of day, and the orientation of the surface. Account is taken to varying degrees of the various lighting components defined for the surface in question, and all this is then superimposed onto the base colour of the material, or the colour from the bitmap texture. The calculations appear to be on a pixel-by-pixel basis (note the rounded surface effects etc.) and the final rendering can vary from darkening the bitmap colour to black, to increasing it right up to white.The shading of the mesh terrain is done in a rather strange and crude way (because there is no vector data etc ?), and this shows up rather badly at dawn/dusk as the terrain lightens/darkens in sudden jumps.I haven't played around enough with the specular component, relection maps, and specular power, to determine how the "impression" of specular reflection is achieved - but you have more experience of this. Again, it seems to be fairly simplistic, but the specular reflection effect from water surfaces is nevertheless quite effective.There is no documented facility in the BGL command set, or through any known global variable etc., for controlling the overall lighting intensity or turning off the light/shading effects. Once upon a time there were the old Brightness and Specular commands, but they are not relevant to the current scenery engine and the opcodes are just ignored. All we can do is adjust the various lighting components of the material.I am planning to do some more work on possible tree models fairly soon and will see if I can find a solution to the problem. The annoying thing is that the Autogen code does seem able to render cruciform trees without the shading problem ...Gerrish

[Guest christian]

Hi Gerrish,this is getting way off-topic, but some answers...>Actually, I was very interested in techniques for >computerised rendering of 3D scenes about 30 years ago, wow, things must have been different back then. I started programming 15 years ago, but always thought graphics programming is too hard and time consuming. I learned opengl not even a year ago, and I was amazed how easy it really is...>i.e. the intensity of the >lighting on a surface is calculated from the position of the >sun, intensity based on time of day, and the orientation of >the surface. correct. You just use a point light source with a given intensity and opengl does the rest for you.>Account is taken to varying degrees of the >various lighting components defined for the surface in >question, and all this is then superimposed onto the base >colour of the material, or the colour from the bitmap >texture. yes. the light colour is used also. Note how in FS2002 the sun light changes it's colour at dusk and dawn...>The calculations appear to be on a pixel-by-pixel >basis (note the rounded surface effects etc.) and the final >rendering can vary from darkening the bitmap colour to >black, to increasing it right up to white. No (and yes). The lighting is done on a per vertex basis, rather than per-pixel. Opengl interpolates the vertex light values over the texture to achieve the smooth effect (gouraud shading). The difference in vertex and per-pixel lighting is this: Imagine you have a spot light. If you are far away and have a large polygon, everything will look fine in vertex lighting, the vertices get their light and interpolate. But if you get close to that polygon, you would expect that you have a bright small spot in the middle of the polygon. Can't be done with vertex lighting. The only solution is to tesselate the polygon to smaller polygons to get this bright spot. That's why per-pixel lighting is the latest fashion. Instead of using light rays, you give the torch light a texture with a round spot (attenuation texture). Now depending on how far you are away you stretch or shrink that texture over the polygon (can be done with 2D textures and calculating distance, or with a 3D texture). >I haven't played around enough with the specular component, >relection maps, and specular power, to determine how the >"impression" of specular reflection is achieved - but you >have more experience of this. Again, it seems to be fairly >simplistic, but the specular reflection effect from water >surfaces is nevertheless quite effective. This is done using Blinn or Phong shading. The Blinn equation is:N dot (L+E)powerN = normal vector, L = light vector, E = eye vector, power is how shiny the surface should be...So basically, when eye and light and normal vector are in the same direction, you maximise brightnessChristian

[Guest GerrishGray]

Hi ChristianThanks for those details. FS always did use Gourad shading, of course, if you gave it the necessary vertex vectors, but now it is automatic as we have to supply vectors for every vertex. How is the specular brightness done though - that must effectively be on a per-pixel basis, or is some other mechanism used? (Not that it matters as regards our practical understanding of FS, but it's always nice to know how things are actually working.)"Graphics programming is too hard and time consuming" - yes, that was why we didn't pursue our project 30 years ago. We researched the basic maths but realised that it was going to be too difficult and time-consuming to program for the application we had in mind, which was a concept we called Computer Reinforced Design (CORD) a 'lightweight' version of CAD for "tailored off-the-shelf" engineering components for design engineers to use on minicomputers. We decided just to stick with orthographic views at that time and leave the development of 3D drawing with full hidden surface removal (and eventually rendering) to those with mainframes and vast resources! With the very limited memory of mini's at that time, it was essential to use vector drawing methods for every aspect - it was not feasible to create a bitmap and use the painters algorithm. I did do some work with computer-generated art just as an interesting sideline - but that's another story!CheersGerrish

[Guest christian]

I had to think about the specular question a bit. I'm reasonably convinced that it's per vertex still. In openGL lighting you still only assign material properties to a vertex.Per-pixel lighting isn't using the standard opengl lighting, but you have to do it on your own. Indeed, even with per-lighting the (L + E) vector is only done per vertex and interpolated over a polygon (how the inerpolation is done I have no idea though). The advantage of per-pixel lighting is that you can supply a normal map (normals encoded into a texture) for a polygon and thus get a bumpy surface, which of course is bump-mapping. Even though the specular highlights are only interpolated over a polygon, it looks very realistic together with bump-mapping.I haven't dug into the newest trend, pixel shaders, yet since my GF4 doesn't support it. It's possible that with pixel shaders (fragment programs) everything is done per-pixel, but the pixel shader hardware would have to be quite powerful.Cheers, Christian