CompuServe Messages

Hi David, I got your message on Saturday, but I promised my boys, no computers, only gardening all weekend so I was involved in teaching my 9 yr old the age old art of double digging… Great fun. The garden is getting better every day.. Great feedback, and a lot to answer so here we go…This is a long one. No it's 2 messages. <<<<I downloaded your NAVFlyer application and loaded the chevy.3ds file. It was incredibly slow and the gouraud shading was dithered rather than using solid colours. Also the lighting was very dark. Is there a way to speed it up and get solid shading?>>>> VR worlds are seldom 33K polys. Even the high end Evans & Sutherland hand gliding demo seen at trade shows (a very fast box compared to a PC <g>) only renders about 1600 polys on the sreen at one time due to some smart logic (level of detail , LOD, and other such tools). However I think the Chevy model is a pretty typical 3D Studio model for experienced users as yourself, so I will try to address your questions regarding this model. Lets save the speed issue for paragraph below on VIEW_I. As you know, the dithering is the method WinG uses to create a better image with only 256 colors. There is no time in real-time rendering (or as close to it as we can get) to optimize the pallette on each frame (many per second), depending on which objects you happen to be looking towards at the moment (and which colors they are). While we do have displays that work in 256 colors without dithering, they are not that much faster nor better looking, without that prohibitive reramping of the LUT to give you great shading. Higher color depth is possible however, read on… The darkness seems to be in the model itself. When I looked at the Chevy model, the ambient was set to 10. I upped it to 100 and put some lights in and the white part got very bright while the red part was still pretty dark. I would suggest that the material properties on the chevy are probably metal with a dark diffuse color (I havn't checked, please correct me if I am wrong) and it renders very dark. I rendered it in 3D Studio to see how it looked there and it was also pretty dark. The demo 3DS files supplied with NAVFlyer don't come in dark, so I would have to assume that the Chevy model may need some alteration to brighten it up. Try the NAVcity model supplied. It is very bright and only 1000 polygons for better flying. <<<<I used VIEW_I.PXP(by Gus Grubba et al) in 3DS R3 to view the chevy car(+33K faces) from chevy.3ds on my 486 DX2 66Mhz and I could rotate the gouraud shaded car in real-time with really fast feedback. There was only a slight lag in the rendering time. When I loaded any smaller object I had immediate real-time smooth feedback. So I know that is possible to get great real-time gouraud shading performance even from my 486.>>>>> I suppose this is a logical question for 3D Studio users. Let me tell you what I know and maybe it will help… maybe not, but for what it is worth…Start by comparing apples to apples as close as possible. If you create a window in NAVFlyer of the same size as the one used in the VIEW_I.PXP and zoom back to where the Chevy is taking up about the same amout of the window as it does in VIEW_I.PXP and put Object Lock on so that it will stay in the center of the screen, on my 486 66 I get around .43 fps. Using VIEW_I.PXP on the Chevy model on my 486 I get around 1.5 fps. Somewhere between 3 and 4 times faster than NAVFlyer. In VIEW_I.PXP there are no colors, so the rendering there is limited to only one calculation. We have at least 3, for RGB so that most likely (as explained to me by the CDK guys) explains why they are at least 3 times faster than NAVFlyer. VIEW_I does not cares if a rendered pixel is on the body of the car or the bumper or the seat. NAVFlyer is constantly making these calculations and rendering the correct color, texture and lighting for each pixel. There are no other viewpoints to consider in VIEW_I while we are constanly checking to see if you have moved in 6 Degrees of freedom (not 2) , released the object lockon or not, all checked every frame. VIEW_I only has to check on how the object has been rotated on only 2 axes, I believe from a quick glance at the source code magnanimously provided by the Yost gurus. Since there are no other options in VIEW_I there are also many other tricks (or talents) that might be being utilized to speed up the rendering. I don't know what they are doing specifically in their rendering library, but such techniques often used by game makers include integer only math, ray casting as opposed to true 3D calculations (often used in games like DOOM where the model is typically orthogonal walls only and very simple to navigate without true 6D control), model optimization and others. It is very interesting that using VIEW_I with the Chevy model on my 486 in Flat its 1.5 fps and Gouraud is 1.3 fps and in wireframe, where you see each edge of each poly it SLOWS DOWN to only .5 fps, very close to NAVFlyer's texture mapped Gouraud speeds. WE generally fly faster in wireframe than shaded, which leads us to conjecture that they have some good techniques in use while shaded that don't work in wireframe. Also, VIEW_I always uses it's own default lights, not caring what the model has for defined lights, thus the lighting model is much simpler. The lights are always positioned in the same place in relation to the camera. NAVFlyer is considering the ambient light as well as additional lights in the model and where the camera is in the current frame, each and every frame. So when you say that you know you "can get great real-time gouraud shading performance even from my 486" I suggest that there is more to consider. The bottleneck is in painting the pixels, so first start of with as close to apples to apples as you can get by making the rendered window the same size and the Chevy at the same distance, so you are painting the same amount of pixels in both cases. Then compare what capabilities are being considered. If your purpose is to look at one object to see it's shape, with no surface considerations or true 6D control, VIEW_I is a better solution than NAVFlyer. It serves a great purpose in helping to create models. However, it is not capable of putting you into an environment to fly around and experience. If it was, it would render slower, period. The more you take into account on each simulation loop (each frame) the longer it takes. We have weighed the choices very keenly over the past few years and have chosen the capibilities that we offer because they are necessary to create a "Virtual Environment". Speed is not great on standard VGA cards yet for anybody, but that will come with time and in the meantime, we feel that (especially for 3D Studio users) there is still a lot that can be done with some immagination and innovation. It is a gamble we are taking, that modelers will see beyond the speed issue and try to create worlds NOW that are NOT 33,000 polygons. Maybe we are wrong and modelers such as yourself will not find it worth it to try, but I am betting on you and others to go for it. I hope I am right <g>. <<<I understand that the VIEW.PXP must be using a "fixed" palette consisting of a gradient for the various light intensities between 0 and 1, but even though you said that NAVFlyer could do the textures I can't see them since the colours are dithered(Bayer dithering I think) so much that the colours are muddy.>>>> Check out the included NAVCITY.3DS and tell me how the dithering on the textures looks there. It is certainly not muddy. The chair in the Chevy did look muddy however. Certain textures will look better than others in dithering I suppose….The goal is certainly to get more than 256 colors if this is a prime concern. Remember though that a higher bit depth also slows down the simulation loop (frame rates). <<<A suggestion: can you have the program work when using a high or true colour display? I used true colour in windows for Photoshop et al and don't want to have to switch to 256 colours, run the video profile each time I want to use your program.>>> Yes NAVFlyer and NAVIGATOR do work with a true colour displays. Using the Rendermorphics display we get true color in Windows and in DOS using SPEA's Fireboard and Future Vision Technologies Sapphire boards. The accelerator cards give you great color and great frame rates too. Watch for the new Sapphire 2SX card from Fujitsu (now) that is supposed to be out by early April (latest date, but you know how that goes <g>). They tell us that there will be versions of the board from under $ 1000 to 1200 or so depending on features. continued on next message……….