| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Also MultiGen Creator can import certain type of 3d File formats |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
A couple of people have had some success in using Borland's C++ Builder, here's the details of what they have done, I cannot say if this will work or not 1) Convert all lib files to Borland compatible.
@echo off Coff2omf -q %1 x.lib >> convertlog.txt if errorlevel 1 goto :fail copy %1 orig_lib copy x.lib %1 echo File %1 copied and converted >> convertlog.txt goto :EOF :fail echo Error in file %1, not converted >> convertlog.txt The Coff2omf routine is found in the Borland executable directory, and should be in the path. This bat file (convertAll.bat) uses the first bat file to convert all lib files in the Vega lib directory. The easiest way to do this is to put both bat files in the Vega directory. cd "c:\program files\paradigm\Vega\lib" mkdir orig_lib attrib -r *.lib for %%f in (*.lib) do MyCoff2omf %%f del x.lib 2) You have to modify the jlu.h file to eliminate a define of ptrdiff_t already defined by Borland:
typedef int ptrdiff_t; #endif 3) In you Borland project, under Project | Options | Directories/Conditionals in the Conditionals Edit box, enter: _DLL;_BORLAND;WIN32
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Vega ships with a simple example project, see <%>Sample\Vega\pguide\ch03\MFCVega |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This can be done in a couple of ways :
In your Vega directories search for "EditPlatform.bat" and run the batch file Then check the USE_OUTPUTDEBUGSTRING box and this will allow out put to the Visual Studio debug window.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Vega and Performer both use large amounts of memory and create their own memory pool and manager. This memory pool other major components of Vega and Performer are only correctly freed when the program Exits. This means that they are not re-entrant meaning you cannot simply initialise start stop and repeat the initialise, start, stop Vega or Performer again by default they both call Exit(0) during their shutdown process. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
No there is no COM interface for VegaNT, ( Vega Irix does have a TCL/TK interface )
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Yes you can use Tcl/TK with Vega, vgTcl provides Tcl//TK bindings for Vega and was created by the talented Mike Weiblen. vgTcl was distributed with Vega on the installation CD's as a vgGift, which means it was officially unsupported by MultiGen-Paradigm although it was maintained by Mike Weiblen.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
vgTcl provides Tcl//TK bindings to Vega, vgTcl was distributed with Vega on the installation CD's as a vgGift, Further details on vgTcl can be found on Mike Weiblen's web site vgTcl readme |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
With Vega there are 2 ways to get properties from Vega Class instances
For example to retrieve the state of a vgChannel we call int state = (int) vgGetProp( vgGetChan(0), VGCOMMON_ENABLED ); See the individual vgClasses man pages for which properties can be retrieved using vgGetProp
For example to retrieve the current filed of view form a channel we call
See the individual vgClasses man pages for what vgGetxxx functions are available |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
For example to change the state of a vgChannel we call vgProp( vgGetChan(0), VGCOMMON_ENABLED, VG_ON ); See the vgClasses individual man pages for which properties can be changed using vgProp
For example to the current filed of view for a channel we call
See the individual vgClasses man pages for what vgClassxxx set functions are available |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
See
vgCommon for more details; vgClassProp and vgGetClassProp are very similar to their related
functions (vgProp and vgGetProp), but they set and return class properties.
Class properties are those which exist at the class level. In other words there
is one for each class, as opposed to one for each class instance. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
See vgObject man pages further details on the vgObject Class |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Note before you attempt to use vgDelete() you must first ensure that the vgObject is removed from all association with vgScene, vgPlayer, etc. See vgObject man pages further details on the vgObject Class |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
See vgObject man pages further details on the vgObject Class |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
See the "How to create a vgObject" Sample code for further details See vgObject man pages further details on the vgObject Class See vgDataSet man pages further details on the vgDataSet Class See vgMotion man pages further details on the vgMotion Class See vgCPos man pages further details on the vgCPos Class |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
See the "How get the vgObject Position" Sample code for further details See vgObject man pages further details on the vgObject Class See vgCPos man pages further details on the vgCPos Class |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
If the vgObject has been attached to a vgPlayer or your using Vega LADBM then using vgGetPos will return 0,0,0 for your position because this will return the only the local position To get the position of the vgObject in this instance you need to get the World coordinates rather than the local coordinates thus we need to use vgGetWCSPos rather than the vgGetPos function See the "How get the vgObject World Coordinate Position" Sample code for further details See vgObject man pages further details on the vgObject Class See vgCPos man pages further details on the vgCPos Class |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
See its a little awkward ;), also not if your doing this alot it would be make sense to create a function and also keep the vgPosition instance around rather than creating and deleting each time ( its faster and stops fragmentation ) See vgObject man pages further details on the vgObject Class See vgCPos man pages further details on the vgCPos Class |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
vgFindPartOccurence will also find a named vgPart of an vgObject. If multiple vgParts within the vgObject have the same name, the 'n-th' occurrence of the vgPart can be directly retrieved by setting the third argument to 'n'.
See vgObject man pages further details on the vgObject Class |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
See vgPart man pages further details on the vgPart class |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
vgGetPos with get the vgPart local coordinates with respect to the vgObject the vgPart belongs to, to get the world coordinate then you again use the vgGetWCSPos function instead of vgGetPos() Not only parts that are DCS's or SCS's will return a valid position all other vgParts will return 0,0,0,0,0,0 See the "How Get a vgPart's Position" Sample code for further details See the "How Get a vgPart's World Coordinate Position" Sample code for further details See vgPart man pages further details on the vgPart class |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Only vgParts that are DCS nodes can be positioned, a vgParts type with vgGetProp ( part, VGPART_TYPE ); See the "How Position a vgPart" Sample code for further details
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
You may need to add other Lib's that you may be using or remove other lib's your not using Here a link to the makefile
OBJECT_STYLE = N32 LCDEFS = -D__STDC__ -DFUNCPROTO -fullwarn -DPF_CPLUSPLUS_API=0 -DOPENGL LCINCS = -I. -I/usr/include/PSI CFLAGS = $(DOPT) $(LCDEFS) $(LCINCS)
BASICGFXLIBS = -lmpc -limage -lGL -lGLU BASICXLIBS = -lXmu -lX11 BASICMOTIFLIBS = -lXm -lXt BASICSYSLIBS = -lm -lC -lfpe BASICPFLIBS = -L/usr/lib32 \ -lpfdu_ogl \ -lpfutil_ogl \ -lpf_ogl
BASICVGLIBS = -L/usr/lib32 \ /usr/lib32/libvgsym.a \ /usr/lib32/libvgsw.a \ /usr/lib32/libvgsv.a \ /usr/lib32/libspv.a \ /usr/lib32/libsp.a \ /usr/lib32/libvgnsl.a \ /usr/lib32/libvgmarine.a \ /usr/lib32/libvgladbm.a \ /usr/lib32/libvgfx.a \ /usr/lib32/libvgdiguy.a \ /usr/lib32/libvgcmobj.a \ /usr/lib32/libvgaudio.a \ /usr/lib32/libvg.a \ /usr/lib32/libvgfst.a \ /usr/lib32/libvgimg.a \ /usr/lib32/libsynclink.a \ /usr/lib32/libxvsutil.so \ /usr/lib32/libaw.a \ /usr/lib32/libawaux.a \ /usr/lib32/libawcompat.a \ /usr/lib32/libawd.a \ /usr/lib32/libawhwi.a \ /usr/lib32/libawin.a \ /usr/lib32/libpsi.a \ /usr/lib32/libaudio.so \ /usr/lib32/libaudiofile.so \ /usr/lib32/libdiguy.a \ /usr/lib32/libdiguy_pf22_ogl.a \ /usr/lib32/libdiguy_util.a \ /usr/lib32/libpfdb/libpfpfb_ogl.a \ /usr/lib32/libpfdb/libpfflt_ogl.a
LLDLIBS = $(BASICVGLIBS) $(BASICPFLIBS) $(BASICGFXLIBS) \ $(BASICXLIBS) $(BASICSYSLIBS)
COMultiGen-ParadigmLER = CC
CFILES = sample.c
OBJFILES = sample.o
EXE = Vega_static_sample
all: make depend make compile make link
fast: make compile make link
# Create Makedepend file depend: Makedepend
# Compile the objects compile: $(OBJFILES)
# Create the executable(s) link: $(EXE)
$(EXE): $(OBJFILES) @echo -- linking $@ -- $(COMultiGen-ParadigmLER) -mips3 -n32 $(OBJFILES) $(LLDLIBS) -o $@
clean: /bin/rm -f $(EXE) $(OBJFILES) core
clobber: clean /bin/rm -f Makedepend
Makedepend: $(CFILES) @if test ! -f Makedepend ; then mkdepend -c "$(COMultiGen-ParadigmLER) -M $(CFLAGS)" -e \\x/usr/includexd -i $@ $(CFILES) mv $(.TARGET) $(.TARGET)= nawk '{ if ( match($$0, /[A-Za-z]/) == 1 ) \ { printf "./" } print }' < $(.TARGET)= > $(.TARGET) rm -f $(.TARGET)= else @echo "updating dependencies for $?" mkdepend -c "$(COMultiGen-ParadigmLER) -M $(CFLAGS)" -e \\x/usr/includexd -i $@ $? mv $(.TARGET) $(.TARGET)= nawk '{ if ( match($$0, /[A-Za-z]/) == 1 ) \ { printf "./" } print }' < $(.TARGET)= > $(.TARGET) rm -f $(.TARGET)= fi
## use the Makedepend file if it exists sinclude Makedepend
.c.o: @echo "compiling $(.IMPSRC)" $(COMultiGen-ParadigmLER) -c $(CFLAGS) -mips3 -n32 -o $(.TARGET) $(.IMPSRC)
.C.o: @echo "compiling $(.IMPSRC)" $(COMultiGen-ParadigmLER) -c $(CFLAGS) -mips3 -n32 -o $(.TARGET) $(.IMPSRC)
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Distributed Vega is a Vega module for low-end hardware such as PCs, in which one system known as the master host drives the visual simulation on a number of other systems known as slaves. Distributed Vega is TCP/IP based to allow systems to be connected to the master via communication media such as LAN, WAN, or cross-over cable. Distributed Vega hides from the user, the complexities of establishing connections, and exchanging data and control information among the systems. It works with both connectionless (multicast) and connection oriented communication and has two modes of operation. The synchronous mode guarantees that each frame rendered by all the systems will be based on the same data. If hardware swaplock is available, the system takes advantage of that. The asynchronous mode allows the slaves to re-synchronize with the master based on a user-specified frame count. All the systems run their own application and access their own copy of the database. 60hz, if your app can run at 60hz on a single machine then you should be able sustain 60hz |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
vgPlayer's can be moved by attaching them to a vgMotion Model, a vgNavigator or again through API using vgPosVec and vgPos. vgObject's can be moved using the vgPosVec and vgPos functions or by attaching to a vgPlayer. Some vgPart's can be moved using the vgPosVec and vgPos functions ( must be a DCS/DOF node) See vgMotion and the Vega Programmers Guide for further details vgMotion Class See vgMotion man pages further details on the vgMotion Class See vgPlayer man pages further details on the vgPlayer Class See vgObject man pages further details on the vgObject Class See vgCPos man pages further details on the vgCPos Class |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
There are two more complex motion models provided are:
There is one further Motion model supported:
The "Input Device Direct" motion model is intended as
a direct interface to the data provided by the various types of
input devices supported by Vega. Further the user may create and define up to six additional motion models for use with Vega See vgMotion and the Vega Programmers Guide for further details vgMotion Class |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Unlike the other motion models, the model does not change position, only its orientation. Spin requires that a button be pressed before any motion can take place. While the first button (left mouse) is depressed, the model will be rotated about its origin around the Z axis. Moving the input device left will cause the model to be rotated clockwise, and moving right will cause the model to be rotated counter-clockwise. If the third button (right mouse) is depressed, and the device is moved up or down, then the model will be pitched up or down (rotated about the X axis). The second button (middle mouse) is used to make the eyepoint appear to zoom towards or away from the origin of the model. While holding the second button down, moving the input device up, the eyepoint is "zoomed" in towards the model, and moving the device down causes the eyepoint to zoom away from the model. See vgMotion and the Vega Programmers Guide for further details vgMotion Class |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The first button (left mouse) corresponds to the accelerator/gas pedal of a car, The third button (right mouse)to the brake pedal of a car The second button (middle mouse) acts as an extremely good emergency brake. It can cause the motion model to instantly come to a complete stop no matter how fast it is moving. The input device position is used to steer the motion model. Moving the device to the left causes the motion model to turn left. Moving the device to the right causes the motion model to turn right. Note that you cannot turn if you are not moving, just like in a real car. If you want to go backwards, just apply the brake when the car is not moving, the car will begin to backup and go faster and faster in reverse. The steering will be backwards, again just like in a real car. Applying the accelerator/gas while in "reverse" will cause the car to go slower and slower until it comes to a stop and then begins to go forward. See vgMotion and the Vega Programmers Guide for further details vgMotion Class
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This motion model behaves similarly to the Drive motion model in that the first button (left mouse) is similar to the accelerator/gas pedal on a car, and the third button is similar to a brake (acceleration in the opposite direction). When pressed simultaneously, the first (left mouse) and second buttons (right mouse) act as a "turbo" thruster option that causes the motion model to go approximately five times faster than it would otherwise. The motion model gains altitude by pushing the stick up (moving input device down), and by pressing the first button for thrust. Turning left and right is accomplished by moving the input device left or right respectively.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
If you think of the database as being a rectangular two dimensional map that has been reduced so that it just fits on top of the current window. The position of the input device corresponds to the location of the player or observer on the map. To increase the viewing elevation, press the second button (right mouse) To lower the elevation, press the first button(left mouse) Note that this motion model, it is very easy to go to any part of the database by moving the input device from one side of the window to the other. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The motion model is very similar to the UFO motion model except that Fly allows you the ability to pitch and roll but does not allow you to hover. The first button (left mouse) acts as accelerator, The second button (right mouse) will stop motion as long as it is held down, The third button (middle mouse) acts as the decelerator. Sliding the input device left or right will cause the object to roll in that direction and pushing the device forward or backward will cause the object to pitch down or up respectively. See vgMotion and the Vega Programmers Guide for further details vgMotion Class. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This model is most useful as an object viewer. The input device first button(left mouse) is pressed, the scene is rotated based upon movement of the mouse. The second button(right mouse) increases or decreases the distance from the center point. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
It was designed to be used in conjunction with the Flight Simulator Motion Model. For this reason the Missile motion model uses an input button not used by the Flight Simulator for fire control. When using the mouse, "fire" is the middle button; using any other input device it is toggle button 0. Unfortunately, the simple motion models already use these buttons and continue to do so for backwards compatibility. Note it is not possible to fire missiles from a vehicle using (say) a Drive motion model (without also applying the emergency brake!) See vgMotion and the Vega Programmers Guide for further details. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The motion model automatically creates 2 internal Isectors that used for terrain clamping and step/stairs detection. The height and depth of the steps that can be negotiated are definable. The motion model will bump up and down steps that are within its range. The first button(left mouse) moves you forward at a constant velocity following the direction of the mouse The third button moves(right mouse) you backwards at a constant velocity The Second button (middle mouse) allows you to look up/down/left and right without move While moving you can allow pan around up and down, the HAT above terrain does not change Pressing all three mouse buttons at once resets the position to the initial start position of the motion model See vgMotion and the Vega Programmers Guide for further details.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The PickFly motion model has also has a vgPicker embedded into the motion model. Allowing items in the scene graph to be selected, high lighted, transformed and rotate. The motion model automatically creates the two internal Isectors its needs to function. One is used for the line of sight intersecting used during the picking action. The second is used to clamp selected items to the terrain. See vgPicker for full details on how the selection process works. The controls for PickFly are: Note the middle mouse button must be held down to move The left mouse button tap + middle mouse held down move forward along the current heading and pitch, holding the left mouse button will add more acceleration. The right button tap + middle mouse button held down move backwards along the current heading and pitch , holding the right mouse button will add more acceleration. The middle mouse held down on its own rotates view around the current stationary position. The left mouse button will select or deselect the item under the mouse pointer, if the items isector mask matches the vgPicker isector mask. The right mouse button with pointer movement will transform the selected item(s). The left mouse button + right button will reset the selected item(s) to their pre-selection position. Hold the input device middle button + left arrow key will move the view to the left. Hold the middle button + right arrow key will move the view to the right. Hold the middle button + up arrow key will move the view upwards. Hold the middle button + up arrow key will move the view downwards. Pressing all three mouse buttons at once resets the position to the initial position of the motion model See vgMotion and the Vega Programmers Guide for further details. See vgPicker man pages further details on the vgPicker Class |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The motion model includes aerodynamic effects, is fully aerobatic, and uses a quaternion based system of angular integrations. The math model used with in he motion model is of a 6 degree of freedom point mass with damped second order rotations. Thrust vectoring is implemented in pitch such that a helicopter or VTOL aircraft can be simulated, and a low speed attitude control system is selectable when aerodynamic forces become negligible. Many of the dynamic properties of the motional model are customizable so that a wide range of aircraft types can be approximated. Due to the limited number of input channels available from the mouse, only a few of the Flight Simulator controls are active when using the default input device. To fully control the Motion Model a BGSytems flybox or similar input device should be used. Mouse operation is defined as:
For other input devices control is:
See vgMotion and the Vega Programmers Guide for further details. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
See vgMotion and the Vega Programmers Guide for further details. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
For the symmetric frustum, both these planes are perpendicular to the line of sight of the viewer. The horizontal and vertical FOV's (fields of view) determine the radial extent of the view into the scene. FOV's are entered as degrees for the full width of the view desired. Entering a -1 for either but not both FOV causes the system to aspect match that FOV axis. For example suppose the horizontal FOV is 45 degrees and the vertical is set to -1. Once the window and channel are sized, the system selects the appropriate FOV degree for the vertical FOV to maintain an aspect ratio equal to that of the channel viewport. Symmetric frustum Also see the following Viewing Frustum Overview Image
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This type of perspective frustum requires six values to define it. Clicking on the Asymmetric Frustum option displays the six entry fields. The near and far values are the same as the symmetrical frustum. The left, right, bottom, and top values define the side planes of the frustum. They are the angle offset in degrees for the plane they represent. See vgChannel and the Vega Programmers Guide for further details.
Asymmetric frustum
Also see the following Viewing Frustum Overview Image
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The Orthographic projection is a non-perspective projection. This means objects appear to be the same size no matter what their distance is from the viewer. Generally used for a Map view or Hud overlay view The sides of the frustum are parallel to the line of sight of the viewer. The Near and Far distances define the near and far clipping planes. The Left, Right, Bottom, and Top values define the frustum side planes. These values bear a direct relationship to the scale of the object being viewed. See vgChannel and the Vega Programmers Guide for further details. Also see the following Viewing Frustum Overview Image
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
On Vega for Irix you have to write some code to show the frame rate, typically in your keyboard handler, as the '~' key is not set up on Vega for Irix
See vgSimple for how to do this in the context of an application and the Vega Programmers Guide for further details.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Unfortunately no you cannot disable the '~' key from displaying the states ( This only effects Vega NT)
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
You have to drop to the OpenGL Performer level to do this, the gist of getting statistics is shown below:
See the Performer documentation for more information on collecting statistics
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Bitplane's are allocated for features such as:
Vega will ask the system for a bitplane specification supplied through the Lynx Windows panel settings or through code, the request may not be granted. When the notification level (in Systems panel) is set to Info or higher, messages tell the user which bitplane configuration is actually being used There are two methods of specifying bitplane configuration Vega.
On Windows you can use a program from nVidia to show the available bitplane configurations http://developer.nvidia.com/object/nvpixelformat.html Color RGB Alpha Depth Buffer Z Bits Samples Stencil Accumulation |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
When ever the position of an instance is expressed in relation to another instance, then vgGetPos will always use relative coordinates(local). For example when vgPos is used to position a part, it is always expressed in relation to its parents. More often the position that is required from vgGetPos is this relative position, but sometimes the absolute or world coordinate position is required. For example when positioning say the barrel on a tank it is easier to use parent relative coordinates, but when the gun is fired, and we will want to put a special effect at the tip of the barrel and thus we will need to get the world coordinate position of that part, in order to correctly position the special effect. The syntax of vgGetWCSPos is identical to vgGetPos. The only classes which support the vgGetWCSPos function are:
Note that if a class is passed to vgGetWCSPos which is not supported, then the position returned is that same as calling vgGetPos See vgPlayer man pages further details on the vgPlayer Class See vgObject man pages further details on the vgObject Class See vgCPos man pages further details on the vgCPos Class
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Vega Supports the following graphics states through vgGFX
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Basically the idea behind LOD processing is that objects which are barely visible don’t require a great amount of detail to be shown in order to be recognizable. Object are typically barely visible either because they are located a great distance from the eyepoint or because atmospheric conditions are obscuring visibility. Both atmospheric effects and the visual effect of perspective minimize the importance of objects at ever increasing ranges from the current observers eye point. The effect is that the perspective foreshortening of objects, which makes them appear to shrink in size as they recede into the distance. To improve performance and to save rendering time, objects that are visually less important in a frame can be rendered with less detail. The LOD approach optimizes the display of complex objects by constructing a number of progressively simpler versions of an object and selecting one of them for display as a function of range. An undesirable effect called popping occurs when the sudden transition from one LOD to the next LOD is visually noticeable. To remedy this SGI graphics platforms offer a feature known as Fade Level of Detail that smooth's the transition between LOD's by allowing two adjacent levels of detail to be sub-sample blended. Vega NT does not currently support Fade Level Of Detail. Heres a link to a Pracitcal overview of an LOD
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
© Copyright 2004-2006 Gordon Tomlinson All Rights Reserved. All logos, trademarks and copyrights in this site are property of their respective owner. |