RabidHaMsTeR.Org

Here's the 'Scientific Data' I gathered so far..

1st, why didnt one of us think of just going to scene selection and toggle through each scene to find which has problems, since the name is right on the menu....Guess maybe you figured I was smart enough to know that on my own

So now being educated these are the scenes that cause a fade to black:

Water_Cubefield (Cube on water), Emboss_Tunnel, Water_Biotunnel

The 'Test Method' - was WITH and WITHOUT Audio in Windowed mode.

When with audio I tried MANY manual random scene transitions IN and OUT. Results when involving those scenes were either Fade to black, Freeze of Black screen or Freeze of Previous Scene until an automatic scene transition took place.

Another issue I know you will relate to buggy ATI but thought I would mention, seems when a certain scene transition occurs. I will 'Lose Video Signal'. If I wait, monitor gets signal again but video is left totally black.
Once during loss of signal I somehow was able to get signal back w/picture but the scan was set to 50hz!

Looks like I can make use of good ole LOGITECH to help debug. Since the MEDIA keys always overide ANY window I am going to assign them as HOT keys to batch files so I can kill process, swap video mode etc...

P.S. Your probably saying Yeah Yeah Yeah go by a nVidia card and leave you alone, right?!

256x256 and 512x256 are fine.

You've got the idea. The numbers are actual pixel width and height settings of each buffer. R4 *has* to use the buffers it does for the complex scenes - there's no real way around it because each buffer contains picture data that will be used later. I have a plan for trying to skin down the amount of buffers that are used, but i'm not sure if it will work - i'll try it soon. A good OpenGL driver should be able to copy a pbuffer to main RAM if it runs out of space, and everything should be fine. Unfortunately it seems no-one bothers too much.

well, for a 512x512 buffer, you'll probably use 512*512*4(rgba) = 1mb of video memory. I'm not sure how many buffers R4 uses, but i guess for a complex fade between two complex scenes it may allocate as many as 30-40. Infact depth info may be stored as well, making the textures 2mb.

By reducing the height by a factor of 2 the picture quality doesn't drop too much (the screen is 4:3 aspect ratio so the pixels are now vertical rectangles, not horizontal) and the amount of RAM used goes down by a factor of 2.

It is possible that ATI only use one format of textures inside the card, and maybe use more space than the theoretical minimum. Infact it just struck me that new video cards (dx9 ones) use floating point colour. I know ATI use 24-bit colour, not 8, potentially making every pbuffer 4mb (with depth info).

Right. Just did some checks. The most PBuffers I can get used is 18 - around 36mb on a standard video card, i guess 72 or more on a dx9 card. Its obviously going to make them a little unhappy.

I'm going to try and get this down by merging the list of Module PBuffers and renderable PBuffers (at the moment i make a distinction between buffers that must still contain data on the next frame and those that don't). I reckon that will cut it down a bit, and then i'll try and flatten out module rendering - quick example:

suppose i have a load of modules, some of which depend on each other... At the moment, i render the top module, and that asks for the modules it needs to be rendered, and so on. The problem is that R4 never knows when a texture is finished. Suppose i have one module reflecting another - after that module has rendered, it has no need for the 2nd one's image anymore, but it keeps it anyway. In a big tree of modules this probably accounts for a lot of textures. especially on scene fades.

Anyway, i'll try and sort this out, and render all scenes before, and dispose of textures as they become redundant. It may take me a few days though - i go back to university on saturday, and i still have to make a robot arm for my final year project so its unlikely i'll get anything done before then

- Gordon

It looks like the more WILD and CRAZY you get the greater the challenge, seems you almost have to ask or detect what video card is used and adjust scene definitions accordingly.

Could you introduce an instruction to manually release pbuffers. You would want to keep the module structure in memory, but just release it's pbuffer when module.release() is called. I know it would make the predefines more complicated but it would be a lot quicker to implement than an automatic garbage collection.

I'm interested because after noticing the rendering quality drop during scene transitions I increased the pbuffer size to 1024x1024. It looked good, but I soon got the slowdowns you explain above. I'd love to go back to 1024x1024.

Sounds like its inevitable, the longer it runs and the bigger the texture size the quicker it will happen. So ultimately for future additional images and modules 'a automatic garbage collector/sorter' of some type is really whats needed but what Chris suggested could be used to 'quick fix' the (texture junkie/high end cards) + later in addition to a sorter?

Is there a way to query video memory size + amount currently consumed and what decides how, if and when the AGP aperture gets used the user software or is that hardware specific?

I ran some more tests using the different buffer definitions so ill sort through it and let you know.

You never did mention why the 'other' scenes faded to black? Do you use some new GL1.3 function that my older card doesn't support or is it the modules complexity/pbuffer usage that it doesn't like?

So you have that 'Robot Arm' coding as well?


Edit : I tried 1024 like Chris for fun...... since it claims 2048x2048 support
.... Ummmm can we say CRASH QUICK
.... They must have meant ONE 8bit texture that size.... Hee hee

I changed R4 to show the contents of the PBuffers that it had in memory as well as the current scene and the results were quite interesting. After leaving R4 running for a while it ended up using 24 textures. I can cut this number down i reckon by sharing the two types of textures.

Anyway, the interesting thing was that for scenes that use BUFLOAD and BUFSAVE, twice as many textures are used as needed. I did it when i was developing to solve a nasty problem: If you render into a pbuffer using the same pbuffer as a texture, nasty things used to happen.

When i get this ordering done, this problem should be fixed and at least 5 textures can be knocked off of the maximum from just the module texture side. Hopefully another few can be removed and the problem should be sorted.

Getting rid of unused textures isn't an issue really - every frame unused textures can be reused. The textures aren't freed until R4 exits because it takes time to realloctae them - you'll notice the first few scene changes in R4 are jerky - and thats the reason.

The only real problem is reducing the amount of textures needed to a bare minimum. I reckon probably 5 is what you could get away with (*some* module caching and a few textures per module) - at the moment the maximum i've had is 14.

Anyway, i get back to uni tomorrow, and i'll give it some more thought then. Ironically i seem to have more free time at uni than at home. The robot arm is coming along nicely Not quite finished in time for uni but basically there - still have to make a controller tho'.

Programming the PIC microcontroller in assembler after C++ is actually quite refreshing though. There's something reassuring about only being able to count to 255, and having a billionth of the memory of my PC.

Good to hear....

To get a better grasp I've been getting a little education from the 'nVidia Developer docs' (Yes nVidia and the ATI ones just to be sure its not a plot against my card) So it will be interesting to see the changes and effects.

Hey, what about taking some images of your Robot Arm in action for a new scene?!

Right. I just changed some stuff on R4 - now the two renderable texture lists have been merged and i fixed something else - The maximum count for renderable textures is now around 17 instead of 24 - its possible that this will fix problems on a lot of cards.

The new version hasn't been uploaded yet because i'm back at uni and i have no net connection in my room yet.

As for the robot arm, i'm not sure about pics/vids of it working, but i'm planning on adding some 3D objects i scanned in. Have a look at for some objects i've done with a simple scanner. The one for the uni project should be much bettera nd it'll texture the objects with the original textures too.

- Gordon

Right. New version is uploaded. Let me know if it fixes stuff. Texture sizes, screen res etc now far easier to change by a menu.

Just cycled for 20 minutes in the rain to get to the computer lab to upload this stuff. Now thats commitment :p

- Gordon