|
|
|
Vega prime |
|
|
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
The way files are loaded was changed extensively for Vega Prime 2.0, with many more option and optimization possibilities added ( these are actually very good changes, but the changes seem to have broken Lynx prime quite badly). It appear that if you try to load models listed in a Vega Prime 1.2 ACF file then you more likely to see the slow or no load problems. The solution for some is to create a new ACF from scratch using the Vega Prime 2.0 Lynx Prime. Alternatively load your models through code, you might want to check the code you use by saving a default ACF to a CPP file and check the vpObject settings This is a frustrating and needless Bug and should have been highlighted in the release notes etc ...
| ||||||
|
Where did the Compatibility Mode go that was in Vega Prime 1.x and Lynx Prime 1.x I cannot find it in Lynx Prime 2.0 The compatibility mode have been retired, and yes this is a good thing. The compatibility mode was an attempt to help uses transition to Vega Prime from performer and Vega Classic were the OpenFlight loader and Vega applied default materials and colours to objects. Thus allowed users to user there models in Vega Prime with out having to correct material and colour issues. Sadly compatibility mode just confused many people and was maybe was a little ill conceived or implemented and really should never have seen the light of day And now its gone but on the upside Vega Prime and Lynx Prime 2.0 have introduce lots of new features and many are on an Advance Tab, there's lots of new properties to tweak and try out on the vpObject's Panel Don't be sad it really is a good thing that is has gone....
| ||||||
|
A common question these days is should I be compressing or not compressing my texture ? One thing it depends on your platform that your models and textures are going to be used on. For instance, compressing on a PC based graphics system (Windows or Linux) is in most case the best way to go because textures that have been compressed are much smaller and faster to use. unfortunately you cannot compress textures on SGI hardware as SGI does not at present have support for compressed textures So on a system that supports compression the yes use it. Note some graphic system while supporting the use of compressed textures do no off the ability to compress a texture. You can use the to_vsb and to_dds tools supplied with Vega prime 2.0 to convert and compress your textures
| ||||||
|
That decision to inline textures really depends on your content and how your content management philosophy. If you decide to inline your textures in your VSB files, then, on the pro side, you do not have to worry about individual texture files, paths, attributes etc anymore. There's a but, however, the VSB file size will bloat considerably . And is you choose not inline, then you open up a door for texture reuse across models. while in-lining will not share resources so you may get duplication, but can help for demos and protecting IP of textures etc. Note Vega Prime currently on supports in-lining in VSB files. You can create your in-lined VSB thru code or to_vsb
| ||||||
|
This depends on your models you are using. The "Regenerate normals" loader option will trashes any old normals and generates new ones and generate normals where missing. The option has "normal tolerance" variable that is basically a dot-product that is used to set the maximum "crease angle" between two faces that can potentially share a normal at a mutual vertex. This basically controls how "sharp" the edges should be, and thus you can change this variable to get better visual results. Typically though you will normally (no pun intended), create you normals and set your shading using fine control in your modeling package such as in MultiGen-Creator. So you really would not normally have to use this option, as it will increase the load time and you don't have fine control as you would in your modeling package But if you have models that have no normals or are bad and or you cannot edit the models then you use this option to give you some acceptable if not perfect normals
| ||||||
|
At this time I do not believe there are any plans to support the format in the near future. Stock answer from certain people will be that you can simply write your own loader, while true this is not practical course of action for most users. The so the only other practical option would be to use a format converter such as Polytrans or Deep Exploration.
| ||||||
|
*.flt OpenFlight ( MultiGen-Creator format files ) *.vsb Vega Scenegraph Binary ( Vega Primes proprietary binary format ) Any other formats need to be converted to the OpenFlight using a format converter such as Polytrans or Deep Exploration.
| ||||||
|
Typically you should be able to use a format conversion program such as Polytrans or Deep Exploration. These offer a good selection of import formats and the ability to output OpenFlight models. | ||||||
|
If you get errors when closing your Vega Prime application such as or similar: "vrwindow::destroy GL Context:current thread is NOT a DRAW thread" This is normally an indication you did not shutdown Vega correctly before you application finished and exited Typically you must first shut Vega prime down before your application exits and you must call certain functions in the correct order .eg.
The functions must be called in the above order and from the APP thread, you cannot safely call these from any other thread such as a GUI thread etc.
| ||||||
|
One thing to check is that the line segments of the isector are long enough, by default Bump isector line segments are only 1 DBU in length. Also you need to ensure you have created an Isector Service manager and associated the bump isector with the service manager. Note that you only need one service manager which you share between all isectors.
| ||||||
|
Some users including my self have found the Font Size in Lynx Prime 2.0 to be very small about 7 or points in size making things hard to read for some, but Lynx Prime 1.x is OK It appears that a change was to the way the font size is set in Lynx Prime 2.0, the new default size does not seem to have been tested too much. There is a work around to this, but you have to edit one of the Lynx Prime configuration files : Open the file $(MPI_LOCATE_VEGA_PRIME)/config/VegaPrime/registry/LynXPrime.vrf Search for a String which should read something along the lines of "MS Shell Dlg,5.7....." or so. The value should be around : "MS Shell Dlg,8.3....." Note that the next time you re-install or update Vega Prime this file is likely to get overwritten
| ||||||
Does Vega Prime Support the equivalent to VGOBJ_CLONE Vega Prime 1.x does not support an object clone method. How ever you can do this yourself quite easily by do the following In Vega Prime 2.0 its now easier to do, as a new function was added vpObject::setCopySource(...), that is the direct equivalent to the old Vega VGOBJ_CLONE
| ||||||
Unfortunately with Vega Prime 1.x/2.0 you cannot currently perform an intersection test with Vega Prime based particle effects.
One rough work around is to:
The bounding geometry is in the scene but not drawn which means you can intersect with it
| ||||||
|
|
||||||
|
Unfortunately there is really no easy way to do this as Vega Prime or most other Scenegraphs as the do not load or store any name attributes of faces There also no guarantee that your face would survive in its original form, as it may become part of a triangle strip, array etc when the file is load and optimized. On crude way would be to have the Triangles/faces of interest modeled with one per group, then you could retrieve the face attributes in Vega Prime as long as there file was not optimized.
| ||||||
|
You will have to uses seperate strings for each line
| ||||||
|
This pretty straight forward, here's an example of how to do this on Windows ( On Irix and Linux just replace, HWND with the correct windows structure )
| ||||||
|
| ||||||
|
This should be pretty straight forward, here's a possible way to do this
| ||||||
|
The method checks the m_bLoadState flag and applies the state if it is not NULL. note, set the state to NULL on the geometry node if you don't want the state applied. Render strategies only deal with "geometry" commands. You can, however, issue "state" commands within the strategy as well. You can also consider deriving a new cull record / factory type and setting it on the geometry node. This way you get to control both methods of state applying. Take a look at the "Extending VSG" white paper for details on how to achieve this | ||||||
|
Transparency may come from the Vertex color, Texture, or Material. Vega Prime will pick up these from the OpenFlight file. thus there is nothing special that you need to do at runtime if you have model it that way Now if you want to modify what you've already modeled in your runtime application . then depending on the modeling technique, you will need to access the corresponding attribute at runtime in Vega Prime. The Vertex color is stored in the color attribute of vrGeometry, the Texture and Material attributes are stored in a vrState, Therefore you will need to perform a scene graph traversal (or get hold of the geometry node somehow else), access those objects via the corresponding API calls (see vsGeometry), and then modify the corresponding attribute. Its worth noting that some of the changes may not be multi-thread safe!!! , the vsgs_dynamic_geometry sample shows how to make it multi-thread safe). The vp_flight_path web sample demonstrates how to "ghost" an entire object. In a nutshell, the sample implements a scene graph traversal that modifies vertex alpha and attaches alpha blend element to the state of the object
| ||||||
|
|
||||||
|
I have successfully setup my distribute my application but the models in my code are only being moved on the master computer and not on the slaved machines You will need to tell the slaves to update the vpObjects, see the function vuDistributed::sync Also see the following sample $(MPI_LOCATE_VEGA_PRIME)\resources\samples\VegaPrime\vp\vp_distributed\vp_distributed.cpp
| ||||||
|
|
||||||
|
If you are getting a warning message along the lines of: warn -> convColor : Color Hue <65025> is out of range <0..1024> - Forcing WHITE POLYGON The color hue warning refers to possible corruption in the packed color indices of the flt file. The easiest way to get rid of the warnings would be to switch from indexed colors to RGB mode In Creator or your modeling package edit the header of the database node of your flt file, check the RGB mode checkbox. Or try and update the colour indices again in Creator
| ||||||
|
Unfortunately as of Vega Prime 2.0 You cannot directly use files create in Maya or 3ds Max You will need to first translate your models to a supported format such a OpenFlight using a third party product such as Polytrans or Deep Exploration. See ( FAQ 108 ) There are also some plug-ins to Maya and 3ds Max to output OpenFlight files which you can then use in directly Vega Prime, try a google to find them
| ||||||
|
Yes you can create your own Motion Model in Vega Prime You can write your own from scratch, you can derive from vpMotion base class and you can even derive your motion model form one the motion models provided in Vega Prime $(MPI_LOCATE_VEGA_PRIME)\resources\samples\VegaPrime\vpMotion\vpMotion_user If you cannot find this sample contact MPI support as it may have been moved to their support only samples
| ||||||
|
Vega Prime 1.0 and 1.1 supported a class and node type called vsSequence. The vsSequence class and node were removed in Vega Prime 1.2 to be replaced with the vsAnimation calls and node which provides the same functions and methods.
| ||||||
|
You can do some thing along the lines of in Vega Prime 1.x
See the vsAnimation documentation for more information Note that vsAnimation was called vsSequence in Vega Prime 1.0 and 1.1 Note in Vega Prime 2.0 ::findNamed(...) has been changed to ::find_named(....)
| ||||||
|
Yes Vega Prime does support P-Buffers Vega Prime 2.0 added direct support for off screen P-Buffer Rendering Vega Prime 1.x does not offer direct support of P-Buffers
| ||||||
|
Yes Vega Prime does directly support 3d textures as of the release of Vega Prime 2.0 Vega Prime 1.x does not directly support 3d textures, although you can use them via Opengl in a draw call back etc.
| ||||||
|
Yes Vega Prime does support 2 Left & Right stereo rending as of the release of Vega Prime 2.0 In order to use stereo capability, it is required that the stereo feature be enable and the graphics card must be capable of rendering in stereo and many PC base cards need to be placed into stereo mode out side of Vega Prime
| ||||||
|
Well for some unknown reason MPI in the Vega Prime 2.0 release decided to change the name of the function findName(..) to find_name(..) This is the type unnecessary API change that drive me nuts, it breaks my code and there really no good reason to it, as this breaks every customer code that use the function. Annoying Annoying and node needed
| ||||||
You can do something along lines of : Note it is important that both the frustum and the bounding sphere are computed in the same reference frame (either world or camera). MPI may have a sample so contact Support to see if they have
| ||||||
|
I have vpChannel object in vpWindow, I want to move it dynamically using say the arrow buttons. However it seems that vpWindow object redrawing only channel area so when I'm updating channel position I get artifacts that do not disappear. technically the vpWindow class does no do any drawing at all, It just provides the graphics context and canvas The drawing is done by the vpChannel instances which define a region to draw into, the region is the only thing a channel can clear. That's why we can overlay channel etc.. One quick and dirty method would be to created an extra dummy channel The new dummy channel is then sized such that it fills the whole of the window and has an empty scene and observer attached as we need the channel to be cleared for us, there is little or next to no overhead from this Then your the second, third channels etc are then size and positioned as normal, you can then move these other channels around with out the artifacts being left behind
| ||||||
|
| ||||||
|
On a Microsoft Windows Based system you could do something like:
| ||||||
|
On a Microsoft Windows Based system you could do something like:
| ||||||
|
Basically the SkyDome is currently Broken in Vega Prime. Why is the Sky-Dome All Screwy when I have a High Altitude While the sky-Dome is centred correctly positioned at the observer's X Y position, it's Z is currently always 0. This is a known issue to MPI, but as yet they have not fixed the problem This is a real issue for most high flight applications, and will be worse the smaller your far-clip plane is There is no real work around or fudge, MPI suggest pushing the far-clip out as this scales the sky-dome and thus will scale the Z. But this will effect the visual appearance of the clouds etc. and will effect your Z buffer by reducing its precision and you will probably have to draw more as well if you push the far-clip out Best course of action is to shout at MPI to fix the BUG.... MPI say this has been fixed in VP2.0 I still find it to be broken though
| ||||||
|
I have a set of vgObjects that I would like to moved around etc as a group, in Vega Classic I could have used a vgPlayer, but how do I do this in Vega Prime. This is really easy in Vega prime and a lot easier than in Vega Classic, simply use and create a vpTransform then add the vpObject as children to the new vpTransform node. Now you can move the vpTransform node, attach it to motion strategy, attach it to vpNavigator and the objects will stay positioned relative to the vpTransform Also the really good thing is that you can easily reposition the vpObjects that are parented to the vpTransform, unlike old Vega Classic vgPlayer Also see the Vega Prime FAQ 79
| ||||||