|
Hi Dproeder,
The information in Jeff's link is mostly aimed at users new to realtime graphics. It sounds like you already know what you're doing.
The workflow for Vizard is the same as what you're used to. VR and video games are built off the same technology, share the same limitations and have the same benefits. VR is mainly differentiated by it's use and peripherals. Everything you have listed above brings the same benefits in Vizard as it does in game engines.
How much you should optimize depends entirely on the scope of your project and the capabilities of the system you will be running it on. That is one key thing about developing for VR - there is typically a lot more control over what kind of system you'll be running it on. As long as the scene runs at a good framerate you're fine. We recommend aiming for 60fps in mono, since this gets cut down to 30FPS in stereo when viewed on an HMD.
We generally recommend keeping the scene specs as follows, though it entirely depends on your system:
Polycount: Under 2,000,000, closer to 1,000,000. Some textured scenes we have worked with go as high as 32 million, however. View frustum culling and backface culling is applied automatically. Backface culling can be disabled. Occluder objects can be used, though they aren't as sophisticated as some engines. Billboards, LODs, and other similar tools can also be used.
Drawables: Under 2000 separate objects, further split by material. UV splits, smoothing groups, and geometry splits in general are pretty much free.
Textures/Video Memory Usage: Low enough to avoid swapping. Generally keep it to 75% of your card's capability, since other programs take a chunk as well. Tiling maps are recommended. Multitexturing can be used and is common (light maps, blend maps). DXT compression, DDS textures, Grayscale (i.e. one 8-bit channel) can be used to improve memory usage. Maximum texture size depends on your graphics card. Modern cards can handle up to 16384px and 32768px textures. A texture atlas approach can be used for some kinds of models, though this is not generated automatically, and portions of textures can't be tiled (max's "crop" feature is not supported).
Materials: The default shader is currently the OpenGL FFP shader so heavy use of baking is recommended. In the current version it is possible also possible to use GLSL shaders, though it's necessary to write them yourself. The upcoming version of Vizard greatly improves the ability to generate and work with GLSL shaders.
Lights: Again, light baking is strongly recommended. The OpenGL FFP limits scenes to 8 lights used for vertex shading. Much better lights are possible with GLSL shaders. Better implementation of lights should be coming as well in the next release.
Avatars: Under 25 in view at any given moment. Our current approach to avatars comes with a lot of overhead. Some optimization that reduces the update rate of avatars based on their distance is possible, but attempting to do crowds is not recommended. We are considering alternative ways to handle avatars.
|