• entries
    422
  • comments
    1540
  • views
    488538

Some progress

Sign in to follow this  
jollyjeffers

68 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.
Sign in to follow this  


6 Comments


Recommended Comments

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?

Share this comment


Link to comment
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.

Share this comment


Link to comment
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

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now