- On a personal level I'm a happier person than I was in 2007. I have more free time ( it is easier now that my daughter is 3 years old, back then she was a newborn) and I'm completely satisfied with my job: my commuting time is less than 20 minutes door to door compared to almost one hour.
- My colleagues in ASD (Amoivikos, iM and Ch3) have more free time. I believe Amusic and Leviathan too.
- As expected, we have accumulated even more experience with demo-making: since Lifeforce we've made some alternative productions (such as Metamorphosis and Rupture) which tested the waters with the scene. The fact that the scene liked our direction gave us an extra boost of confidence.
- Better equipment and hardware: I wrote all of lifeforce on a crappy 17 inches CRT monitor using a geForce 5600. I had to see things on a 400x300 pixels window. Now I have 2x 24'' monitors and a pair of geForces and ATIs. I run the demo in full resolution.
- On a technical level: big change is moving from Cg to GLSL. It made my life so much easier as I have direct access to the OpenGL state machine.
- Use of .obj files instead of .3ds. Now I don't have to ever run 3D studio again! textures and shaders are hardcoded in code rather than from inside the .3ds file: much faster.
- Use of shader model 3.0 instead of 2.0: I use loops and conditionals to put a lot of the demo logic inside a big shader file. Rather than having one different shader per material I now have one shader for many materials that share some functionality.
- Use of flexible buffer objects: a big step forward from using the inflexible pbuffers (in 2007).
- Use of deferred shading to achieve effects such as SSAO. This means that I don't have to do any pre-baked lightmap ever again. So no more horrible Blender. All I need for modelling is Wings3D.
- All this results in a much smaller package: Lifeforce had 12 distinct parts which were coded in separate .cpp files. Each file was around 3000 lines. So that was around 40 seconds per part and 75 lines of code per second. Ideally I want to maximize seconds per part (in order to make the demo more "tight", to rely on less camera/mood changes and things that can go wrong with transitions) and also minimize lines of code per second. Iconoclash stands, at the moment, at 120 seconds per part and 30 lines of code per second.
- Compilation times for the project are also down to a couple of seconds (on my new and more powerful computer). I also have a way to reload shaders on the fly, so I can change shader code - press space - change again all in realtime without the need to recompile and run. It used to be the case that I had to re-ran the application once every 20-30 seconds. Now it may take 10 minutes before I have to make a change that requires a recompilation.
Είσαι πράγματι *ΤΟΣΟ* ανόητος;
8 years ago
When you're doing purely shader editing, there are apps that let you load an object (or use a default one if cube/sphere/teapot is enough) and edit the shader while it's running, with handy sliders for setting parameters and stuff. It's not always suitable, but when it is the difference it makes is like the difference you experienced going from full recompile to your current setup :)ReplyDelete
I never liked these things. It takes forever to set it up with all your resources and all this for what? for the extra sliders on the side? I don't get it.ReplyDelete
Yeah, if you're working on a shader that requires your art and everything else to be present, forget it. If you're working on a shader you can test out on a teapot or just as a background effect, these tools take pretty much zero time to set up, and those sliders on the side save you a bunch of time and/or coding. Just a case of 'right tool for the right job' really.ReplyDelete