• entries
422
1540
• views
490898

# Some progress

119 views

I've made a lot of progress with my dissertation in the last couple of days - now that I've got over the really n00b bug I had last week [headshake]

Most of the changes are internal bug fixes, refactorings and general non-visual type things. There are however two obvious (I hope) changes in the above images:

1. White background with a grid "floor". Thought that looked better and more CAD-like...

2. More objects - 10 to be precise. I implemented texture pooling today, meaning that I can have unlimited clones of the same object without exploding my VRAM budget. Dropped the sucker from ~119mb in fullscreen down to a mere 67mb [grin]

I'm probably gonna look into the HDRI tone mapping later, which will hopefully make for some pretty screenshots.

A "mere" 67MB? For just two textures, and the back buffer (oh, and I guess a few more KB for the VB)? Can you give any idea on what the total memory breakdown in your program is?

It's randomly determined! Totally random!

while(abs(rand.next())+1)
Blah = new int;


?

67 MB ? Your two screens report a VRAM usage of 22 MB and the whole scene is in view..?

Quote:
 67 MB ? Your two screens report a VRAM usage of 22 MB and the whole scene is in view..?

He mentioned that it used 67MB in fullscreen mode, while the screenies are from a windowed mode.

Dunno what difference that would make though.

Quote:
 Can you give any idea on what the total memory breakdown in your program is?
I most definitely can [smile]

Quote:
 It's randomly determined! Totally random!
Quote:
 while(abs(rand.next())+1) Blah = new int; 
I experimented with random allocations, whilst they do give the best results the problem is cleaning up afterwards. If you create a random number of allocations it's a bugger trying to guess the same random numbers again to deallocate the same pointers [lol]

Seriously though...

The textures that you can see on screen amount to around 16mb in total (normal+specular+diffuse @ 1024x1024 with full mip chain), the extra memory is all in intermediary buffers/targets.

There are 3 floating point (either 64bit or 128bit and the same size as the output/display) render targets that are used to accumulate the lighting content.

I also have a single 2D shadow map for the directional lights and a single cube shadow map for point lights. These are either 16 or 32 bit floating point.

There is another "light contribution" temporary that allows for post-processing the shadows (to get a simple form of soft shadows).

There are a set of luminance and HDRI post-processing resources, all at either 32, 64 or 128 bit floating point precision. These aren't currently used - when I've finished this I'm going to be carrying on work with the tone-mapping/HDRI component.

It's not the most efficient I will admit, but at the same time - the visuals I've got at the moment aren't actually utilizing much of the planned/designed pipeline [smile]

One last thing - regarding those screenshots showing 22mb instead of 67mb... because most of the aforementioned buffers are post-processing related and/or the same size as the display, it's *very* dependent on the current resolution.

Cheers,
Jack

## Create an account

Register a new account