I needed to alter my methods and streamline the process. So, in January, I made some new year's resolutions that I thought would help:
- Ditch Cg. I've been using Cg for almost 7 years and it served me well. But with the advent of GLSL, Cg is pretty much obsolete. So gone are all the little nuisances and extra C code to "link" my external variables with the shaders. GLSL works much more transparent and I need fewer recompiles.
- Ditch Blender, Maya and 3D Studio. I admit that I'll never become a master of those modelling programs, as I don't have the zen-like calm of a Tibetan monk to learn (of all things especially Blender) properly. They may be super-programs but for me they have always been a source of annoyment. First of all having to run them in the first place adds time! I will be doing something in code in visual studio and then I need to scale something in Blender or 3D Studio. All this process of run/load/finetune/save is costing in time. Part of the reason things had to be like that was my old insistence and total reliance on the .3DS format. There are historical reasons for that (the first "engine" that supported bump mapping, in planet risk, was using certain tokens in .3DS files). But that should change. So, ditch everything except, of-course, my sweet Wings3D - and use the .obj (Lightwave?) format. Yes, it is very primitive, loads slow and probably won't let you do materials and textures, at least with my loader. But it has everything else I need: geometry, UVs (if you need them, I never do), hard/soft edges, grouping of objects. Simplified my life by looong margin.
- Never do another "baked lighting" texture again. It takes forever to auto-uv and bake the model in annoying Blender. I still remember the absolute nightmare that Size Antimatters (which uses such textures extensively) was. Nice way to spend your evenings, waiting for the radiosity pass to finish!
- Start writing everything in a linear fashion. Start with Part 1, 2, 3 ... last part. And keep "parts" as long as possible, in order to reduce the number of total parts and hence complexity. Lifeforce had 11-12 parts, I'm aiming for a maximum of 6-7. It should make a lot of difference at the end when we have to link everything together (music and parts).
- Put more "program logic" (i.e. if (time>20) do this ..) in shaders, using ps3.0: conditional, loops. As a result, the complexity of the C++ code has gone down dramatically. Most of my code is now shader-work. I estimate that the C++ "engine" is probably around 80% down in lines of (horrible) code compared to Lifeforce. Important exception to this is the camera-work and all functions associated, and I'll explain more in future reference.
- Speaking of shaders, allow for reloading of all shaders for a given part while the demo is running (by pressing the space key). This has already reduced the refinement cycle times by a long margin. An additional tip is this: I put all my "real-time user-defined variables" (mouse position, buttons etc.) as arguments in *all* shaders. So if I want to fine-tune something and then something else I can do it with the mouse without having to restart the demo. It works very well.
- Keep and use 2 computers for coding: one with a crappy NVidia 8600 and another one with a more modern ATI 4850. Do most of the coding on the 8600 and only occasionally try the demo on the 4850. Aim for a 16-20fps at HD on the 8600, it should be sufficient.
- Stop watching vimeo videos and xplsv.tv, trying to get "inspiration" (or, in other words, steal other people's ideas). It just doesn't work with me - usually a static image (one that is actually unrelated to computer graphics and effects) does the trick: a photo of a city, of a fruit, of a weird animal is more inspiring than most copy-and-paste "motion graphics" videos (some of them are really cool, though, and carry concepts I wished I had thought of myself).
I'll stop here for now. Yesterday someone asked me if my estimation of "33% of demo completed" is accurate or not. It really isn't, but I want to think it is, to give myself some courage.
+1 on Cg->GLSL. If for no other reason, then being able to use ps3.x-level shaders on !nvidia-hardware. Too bad though, I kinda prefer Cg/HLSL :)
ReplyDeletehornet/loopit
I whole heartedly agree on that 3d modeling part. 3DS max/Maya pretty much killed moppi :( So much of our ideas were tied to some animation to be exported from a modeling package. There are so many demos which never saw the light of day simply because I ran out of motivation on writing exporters.
ReplyDeleteEven for some recent work stuff (such as Zen Bound on iphone), I like to do simple modeling in Silo 3d and then do procedural stuff on top of that.
Damn you 3DStudio, you killed one of my favourite groups.
ReplyDeleteMaybe you can try Wings3D Memon
I have really hard time accepting wings3d UI. I cannot live without that axis gizmo thing, and pressing thre buttons just to move an object is too much. If I knew Erlang, I would fix it, but it is just too weird language to get into. Silo3d does it for me (not too expensive either), although their support/update seems a lazy.
ReplyDeleteOBJ comes from wavefront, nothing to do with lightwave, and it does support materials and textures, take a look at my obj loader: http://nuclear.dnsalias.com/tmp/scene_obj.cc
ReplyDeleteAlso about GLSL, I'm a big fan. I especially love the "varying" mechanism. No more having to shove everything into tex-coord slots and keeping track of what goes where.
oh ok, wavefront then.
ReplyDeleteObj can support materials and textures yes, but I don't use them.
Memon: Wings3D offers plenty of different camera modes (try another one from the 'auxiliary' menu).