Jump to content
  • Advertisement
  • entries
  • comments
  • views

Some progress

Sign in to follow this  


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  


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
67 MB ? Your two screens report a VRAM usage of 22 MB and the whole scene is in view..?

Share this comment

Link to comment
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
Can you give any idea on what the total memory breakdown in your program is?
I most definitely can [smile]

It's randomly determined! Totally random!

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.


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
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!