Being the sneaky, conniving, no-good sonofagun that I am, I slyly replaced my headshot in the previous journal entry with one that isn't quite so frightening to small children and furry animals. Don't like it? Tough. I simply can not make myself look any less ugly; an artist is only as good as his medium. [razz]

In a childish fit of pique against a surge of anti-Americanism that seems to have been running pretty strong there (and here as well) lately, I abandoned #gamedev. In other news, progress on Golem3D is expected by experts to surge to all new highs. [grin]

I've been re-factoring the game object system, blending some of the best aspects of what I was doing with Golem 1 into some of the stuff I tinkered with in Accidental. I'm experimenting with a full-blown object factory, rather than the haphazard set of dedicated object creators that Golem 1 had, to centralize all object creation in a single place. I still am pretty weak on design in this part of the game creation phase. (As I mentioned before, I have far more practice at constructing the foundation 'engine'-type code, due to how many 'engines' I have constructed in my life.) I'm still struggling with issues of ownership, with proper encapsulation, etc… Washu would be proud of me as so far I have successfully resisted the siren call of using a singleton. No singletons are in evidence anywhere in Golem3D. [grin] (No comment on mono-states, though; I ain't perfect. I reserve the right to shut the hell up lest I incriminate myself.)<br><br>I've discarded the idea of implementing some sort of realistic physics, and am cleansing the tiny little tendrils of ODE linkage that I had introduced. From a gameplay point of view, I don't really need it and it stands as a good place to simplify things in order to facilitate the timely completion of this project.<br><br>Still no progress on the shadows. I've thought about simply projecting object models (or simplified versions of them, if poly counts are going to be a factor) onto a horizontal plane, substituting Y coordinate values for terrain elevations, and rendering the projected model in a separate pass after the terrain is done. I'm not certain how well this will work, since it is possible that some portions of the terrain may actually protrude up through the shadow layer and look like ass. The immediately obvious fix for this (fiddling with the z-buffer) has it's own inherent weirdnesses to beware of.<br><br>I briefly looked at stencil shadows, but I understand there be patent-dragons lurking down that dark path. Not to mention the increased hardware requirement, which I would rather like to avoid.<br><br>I could also do a shadow-mapping scheme where I calculate the exact terrain nodes that a shadow occludes, generate texture coordinates into a shadowmap texture (this shadow map texture could be built on the fly after the object is posed for rendering, or pre-generated for each of a model's keyframes when the level's initial lighting is first set up) then re-draw an additional pass for those terrain nodes with the shadow map texture. This would avoid the possibility of bits of terrain poking through the shadow, but I would have to do a little figuring on the best way to do it using the existing engine framework and without adding too much computational overhead. It's possible that I would have to add an additional buffer for texture coordinates (thus further inflating memory consumption) which would be modified on the fly.<br><br>Shadows are turning out to be a little more complicated than I had hoped. It's what I get for not doing any research or experimentation with them <u>at all</u> until this point.<br><br>EDIT: Just now noticed that I've been a registered member now for exactly 2 years. Yays. I won't comment on how long I lurked as an AP before registering, though. Suffice it to say, I remember the old split gamedev/dictionary click-to-enter splash screen, and remember it fondly.<div> </div>