email:  password:

Browsers - Cortona VRML Client - Cortona Renderer

[reply] [back to forum] [new message] [all forums]

Subject: Re: Forcing DirectX Sender: owen@atmos.umd.edu 19.07.01 12:52 >>Interesting discussion about renderers. >>I like Dolgov's promise of a computer >>crash. Maybe we could all quit and go >to >>the beach ... > >To be honest, I never thought about the >humorous aspects of the deal :))))) >Anyway, I've seen such kind of behaviour >for instance on a lot of notebooks - >they allows to switch DirectX on but >then hangs fatally (and they behaves the >same way even if you try to run standard >DirectX samples). And if the default >renderer is DirectX user just have no >chance to view 3D and moreover, to >change something Re:Humor - If I lose my sense of humor, I lose my sanity. Re: various hardware,software,rendering configurations - I agree that it is very aggravating to obtain different results with different configurations, particularly if a good piece of code either hangs or causes a crash on some systems. This stuff is hard enough for me already! Re: Renders - I haven't experienced any crash problems that I can attribute to the renderer, but I have certainly seen visual differences between renderers (and vrml plugins). The example I shared with you ealier using IndexedFaceSet facets joined along an edge with different coordIndex values for the edge points nevetheless smoothed and shaded with COSMO but not with Cortona. As you explained, my indexing was wrong by VRML standards, but COSMO did it anyway with both Direct3D and openGL renderers. The smoothing and shading by COSMO of the VRML-incorrect case is evidently an unofficial forgiveness by COSMO. I am still working to clean up my procedures. In another example, COSMO will forgive a floating point xDimension and zDimension in the ElevationGrid node, which is not VRML-correct. Cortona picked this up, and helped me clean up that part of my code. The most curious differences in on- screen visualization come when I render a surface (say, flat or wavy IndexedFaceSet) behind or through an isosurface (also IndexedFaceSet). (An example would be an earth surface weather map (IFC) with a cloud (isosurface IFC) hovering above it in the virtual sky.) As I grab and examine this visualization, the weather map does not always appear to be "beneath the cloud" (relatively speaking). As I Examine the scene with my mouse, a portion of the cloud isosurface (not all of it) may appear to jump underneath the weather map rather than remaining "above" it. This is very much dependent on the Examine interaction geometry, and I assume it has something to do with arithmetic in the renderers (or perhaps the plugins). I have not figured out how to control this behavior. Another example: positioning opaque Text slightly in front of an opaque Texture may produce different results with different renderers. In some plugin- renderer configurations, the opaque Texture in the background will mask the Text in the foreground so that you can't see the text. Same with geometric objects and Textures placed slightly in front of the opaque Texture. The relationship is dependent on zoom, and if you go in very close, everything is fine. Again, I suspect this is an arithmetic or roundoff problem, and my workaround is just to increase the separation a bit until the same result occurs with different configurations. One more thing: When I work a long time on VRML development on a Wintel platform, the machine will often not shut down, and has to be forced off. Also, I cannot absolutely rely on what I see after long hours of work without a shutdown and reboot. I have been told that this may be due to an operating system feature that won't release memory after the available RAM has been filled. At that point, I expect that crap is hanging around in memory. I would certainly expect rendering glitches due to this OS feature which have nothing to do with the VRML code. None of this I am registering as formal "forum" questions, so don't worry about it. I am just trying to get my computer to crash so that ... well, you know. Owen   [reply] [back to forum] [new message] [all forums] Re: Forcing DirectX / owen1@starpower.net / 18.07.01 21:42      Re: Forcing DirectX / dolgov@paragraph.ru / 19.07.01 04:34          Re: Forcing DirectX / owen@atmos.umd.edu / 19.07.01 12:52 Messages in thread: 3 [reply] [back to forum] [new message] [all forums]