Sign in to follow this  
Guest christian

Has anyone solved the

Recommended Posts

I just finished building a few trees to use in my scenery designs, and I noticed that although I can remove the shadow from the trees in the BGL file, I can't seem to eliminate the modeling of light and shadow on the tree itself. That is, if I make some standard cruciform trees, there is a definite light side and shadow side. This has the unfortunate side effect of really highlighting the fact that they're cruciform. Has anyone figured out the switch in BGLC that turns this sort of thing off? I know I can make them self-illuminated to kill the effect, but I'm not keen on neon glowing trees at night.Any help would be greatly appreciated.thanks,

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

I don't have a solution either, but what do you mean with "highlighting the fact that they're cruciform"?I agree that the lighting effect is not always very nice, but I have no big problems with it on my trees.Arno


Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

Share this post


Link to post
Share on other sites

I just meant that, depending on the position of the sun, there's a sharp line dividing light/shadow that runs perfetly up the trunk of the tree, making them look much more like two perpendicular planes, which of course they are.

Share this post


Link to post
Share on other sites

Aah, that's the problem then :), I have no two perpendicular planes, my trees are made of one plane that rotates to the direction of the user. That why they look better.The only thing you can still see is that they are a lot darker in the shadow then in the sun, but there are no line or so on it.Arno


Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

Share this post


Link to post
Share on other sites

Arno,I have been trying to find a way to change my trees from 2 intersecting planes to a single rotating plane.I cannot seem to find anything in the SDK regarding this. Would you mind pointing me in the right direction (i.e. which instruction set and/or parameters) ? I am familiar with both the BGLC and SCASM commands, but I am currently using BGLC, so I am particularly interested in this.Thanks !Allen

Share this post


Link to post
Share on other sites

Just to throw something completly wacky into here. Has anyone heard of a program called SpeedTree (http://www.idvinc.com/speedtree/)?Using reasonable LOD models this may be a new milestone in scenery design. Unfortunately, I don't really have time to look into this myself. I dunno if this approach would be reasonable at all, it just may be too many polys even with good LOD models...Cheers, Christian

Share this post


Link to post
Share on other sites

I can't remember the BGLC command (I am at work, have no SDK etc here), but the SCASM command is RotateToAircraft, if you put this at the place of the RotatedCall then it should work fine.For BGLC it would required finding the equivalent command (I have done it already at home) and then placing it in the BGLC file (made by GMax for example).Arno


Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

Share this post


Link to post
Share on other sites

Humm, demo is not that usefull, only shows nice pictures.Also bit expensive to buy ($400 or so) and I haven't found an example tree in AutoCAD or 3DS format so I can test it with GMax and FS.Arno


Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

Share this post


Link to post
Share on other sites

Hmmmm ...Several hundred to 25,000+ polygons per tree (and only costs $400 or so) - not quite the ideal solution for FS, methinks! Nice thought though.CheersGerrishBTW, the BGLC version of RotateToAircraft() is SPRITE_VICALL.

Share this post


Link to post
Share on other sites

Yeah, after my first enthousiast reaction I have been thinking a bit and although the lowest detail model should "only" have a few hundreds of polygons, I think they can never win from the one rotating polygon with a good texture.Arno


Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

Share this post


Link to post
Share on other sites

Hi BillI agree with you 100% about the unsightly effect that the differential shading has on the traditional 'cruciform' model for trees when used in recent versions of FS. This was one of the reasons why I and others adopted the alternative RotateToAircraft() method.There is no way in FS2002 (as far as I know) of curing the problem with the cruciform model, because all of the available texture-rendering commands produce a similar effect. I suppose that this is an essential feature of the scenery engine in order to create a correctly-shaded 3D world. But it's a pity that there is no way of turning this light-source dependant shading off for the special case of trees. The separate code for the Autogen trees appears to do exactly that - they don't seem to suffer from the same problem - but the rendering technique that Autogen uses doesn't seem to be accessible to us in BGL code. I'm just praying that RotateToAircraft() (SPRITE_VICALL) will still be there in FS2004 when they are seemingly going to strip out a lot of the older BGL commands ...CheersGerrish

Share this post


Link to post
Share on other sites

Hmm, I only had a quick look, and thought they have 3ds trees, but they are in the spt format. So the demo is only movies then? That's useless.I was thinking having quite an aggressive LOD sceme, with still having billboard / crossmapped trees from further away. A GF3 should be able to handle about 10 trees without noticeable performance drop at small airstrips.As to billboards, they also drain CPU power, that's why those crossmapped trees are still around (ie if the autogen trees would be billboards, that would be noticable in framerates). Imposters is what we need.The only thing I don't like about billboards / cross trees is that they look stupid from above and can't cast real shadows. I've seen demos with more highly detailed vegetation (100-1000 polys per plant, and I'm talking free roaming realtime landscape simulation here) and GF3 and up are certainly able to handle that sort of detail. Hopefully MS will optimise MSFS eventually (I thing FS2004 will be unlikely though), so we can include 1000 poly trees for autogen...Ahh, I'm dreaming again...Cheers, Christian

Share this post


Link to post
Share on other sites

Actually the Autogen trees do have an appreciable drain on frame rates - try turning up their size and density with the Annotator and you'll see what I mean!Quite apart from the shading problem, any model with intersecting planes is a pain to draw, even if your name is DirectX, because it needs more than the simple 'painters algorithm' to resolve the hidden surface issue. For every pair of intersecting triangles, the line of intersection has to be calculated and the two original triangles clipped/divided into smaller ones. That's why gMax has the 'weld' facility and recommends its use in preference to allowing parts/planes to intersect. This way, the calculation of the intersection line and splitting the triangles is done as a one-off calculation at design time.So the cruciform model for trees is far from ideal unless one welds the intersecting planes and turns them into at least 16 triangles rathen than 8 intersecting ones. The single plane rotating towards the viewer has many theoretical advantages, including the fact that it reduces to just two triangles, but its drawback is the considerable overhead of the rotation mechanism. I have no idea whether DirectX has a 'primitive' for this, but even if it does it hasn't been implemented in FS yet. I've got some ideas of my own for optimising frame rates in the next version of my trees library ... 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).CheersGerrish

Share this post


Link to post
Share on other sites

>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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this