Jump to content

  • Log In with Google      Sign In   
  • Create Account


Triangles-PCT

Member Since 23 Oct 2011
Offline Last Active Today, 01:47 AM

Topics I've Started

Precomputed Atmospheric Scattering

20 January 2012 - 08:50 PM

Hello--

I'm implementing Bruneton's precomputed atmospheric scattering and have stumbled over a slight issue.

I can always see the outline of the planets sphere, even through terrain.. here is a photohighlighting the problem to demonstrate.


Looking at other photos people have posted with this algorithm I actually see that many of them exhibited the same problem...

Here, another post on gamedev, in the first photo, I see the sphere through the terrain...

This photo also contains the problem


Does anyone know if there is a way to avoid this rather ugly artifact?

Thanks

C++ header only style

04 December 2011 - 09:58 PM

I hate the way C++ uses separate interface and implementation files, so I decided to try a little experiment to see if it might be possible to just use headers.


Testing to see if using a header only approach to C++ has any benefits, by this I mean that each project would only have 1 .cpp file, everything else goes in headers.


All tests done with Visual Studio 2010

Code includes use of many templates, STL, boost, and TBB(lots of templates).


LTGC is on for release built, along with comdat folding

/MP is also enabled for all builds, although in header only world it doesn't do much(anything?)


Using CPP files: size: release = 375,296 bytes debug = 1,856,512 bytes
Using header only: size: release = 375,296 bytes debug = 1,856,512 bytes


So using 1 CPP, instead of many, made no difference to exe size



Full Build Times Release:

CPP Header:
1)33.74 1) 18.17
2)33.79 2) 18.02
3)33.48 3) 18.44



Full Build Times Debug:
CPP Header:
1) 24.65 1) 12.47
2) 25.16 2) 12.11
3) 24.80 3) 11.76



Full rebuilds are much faster under header only, and this is with /MP(multithreaded builds) enabled(8 cores) which favors having extra .cpp to split up the work


Partial Rebuild Release:
CPP
1)16.18 <-- changed 1 line in 1 cpp
2)25.81 <-- changed 1 line in random .h
3) 13.66 <--- changed 1 line in a different cpp


Can't do partial rebuilds with header only, but full rebuilds with header only are comparable to partial rebuilds with CPP's time wise. Partial rebuilds heavily depend on exactly what was changed


Partial Rebuild Debug
1) 19.06 <-- changed random header by 1 line
2) 3.32 <-- changed a line in 1 cpp
3) 16.62 <-- changed a line in another random .h



The code was all originally written using .cpp/.h combo as traditional C++. To switch to header only I just copied the contents of each .cpp under the contents of the .h and then removed the .cpp from the project.


After I had finished this I only had one compiler error which resulted from two objects which both made use of each other. One by value and one by reference.


I fixed this by splitting the class which used the other by reference into two headers, the .h as it had already existed, and contents of its .cpp moved into a .hpp and included in a header called "circular.hpp" which is then included in the one and only .cpp(main.cpp).


+ could probably also just rename all .cpp to .hpp and add them to circular.hpp or some such which is included in main.cpp, but this keeps those extra files around...


I had expected it to decrease the size of the .exe(or at least change it) since I've heard of other people doing similar things to create more optimized builds, and of course people crying about template bloat. That didn't happen though.


Built times are better in many cases, slower in others. I could see the header only approach not working so well with a giant project as it pretty much results in constant time builds which grow linearly with the # of files.


Of course changing a header in a giant C++ project can result in a nightmare rebuild...


Perhaps the best way would be header only, but split into multiple projects, so that not everything must always be remade?


Overall Header Only:
+faster worst case build times(changing a header)
+simpler build process
+can place code right in the class itself, like in most modern languages
+less files to deal with
+less worrying about forward declaring to avoid excess header includes and PIMPL pattern
+only one translation unit so warnings/errors in headers are seen once(less spam)
+can write functions in header without being forced to "inline" them (normally this results in multiple definitions error but with only one translation unit, no such problem)
+on older compilers that don't have link time code gen, should be more optimal?

-best case build times are slower(changing cpp)
-might not scale too well? not sure here, might be easy to work around this with multiple projects


I think I am going to start doing this with all of my code, and port my existing code over to this approach..

Does anyone have any experience with this, or know of any problems I missed with this approach?



C++ needs a module system:(

PARTNERS