I’m currently in ‘pencil chewing mode’, which means I’m considering the best way to go about implementing shadows in 0.14. I’ve posted extensively on my thoughts in this thread: http://www.ogre3d.org/phpBB2/viewtopic.php?t=3271,and I’m currently reading all the shadow papers I can get my hands on. Work is a bit nuts right now though so I’m rather fried by the time I get home, so real work will probably have to wait until the weekend.
Sorry for the quiet period, I’ve been flat out getting the OGRE 0.13.0 release ready for public consumption, and then recovering from all the hours I put in on that process afterwards 😀I’m glad it’s done, 0.13. is a big update and really starts to put OGRE on a par with the next-generation commercial engines (I think our fresnel reflections are as good as HL2’s, although of course there’s a lot more to their engine).
Boy, am I having a bad week. Work has been highly busy, one of my key staff is leaving, and my laptop died, seemingly from a burned out graphics chip (it won’t go above 640×480 now without barfing). When it rains, it pours. On the good news side, fresnel-modulated reflections are now working, see them here. temas has also merged in the GL_ATI_fragment_shader support which nfz wrote, so we support ps_1_x on ATI cards in GL now too, which is great; it even converts ps_1_x code to ATI calls so we can use Cg to drive it.
I’ve been playing with texture projection and distortion these past couple of days, in preparation for a new water effect. I abstracted a Frustum class out of Camera in order to provide a good way to get a view / projection matrix out for use in texture projection, and that’s worked well - I have a bit of tidying up to do in Camera so I can make it a Frustum subclass, but that can wait for the moment.
It’s been a bit slow going these past 2-3 days, I’ve been fixing a few minor things, sorting out the 0.12.3 maintenance release and such. There was also an odd release-mode only bug in DirectX9 that would only occur on some demos, and then only when you ran in Dx9 twice; if you ran in GL or Dx7 in between it would work again, the first time. Debug mode was fine, so I suspected an initialisation problem.
Sods law says “If you have plans for something, forget about it.”, or something like that. I’ve been fixing up a few things in the last couple of days, mostly issues with using multiple render targets; there were some problems with overlay sizes and frame rate stats when using more than one. I wanted to do this because the demo I have planned will use 3 targets; 2 render textures and the main view.
Happy new year to everyone! I’ve pretty much finished all the texture flipping business, _mental_ is working on DDS /volume texture / compressed texture support for GL now and in the meantime I’ve been fixing a few miscellaneous bugs, like a problem with a boundary condition on the mesh LOD generation and some issues with overlay sizing when using multiple render targets (like in the render to texture demo). I’m also propagating all the bugfixes in the pending 0.
Well, xmas is over and I actually had a little bit of a break from OGRE for a change. Nevertheless, I did sneak back to the keyboard at least a few times over the last few days, and the result of that has been that I got the nvparse code working, which is good news for GL users owning GF3’s and GF4’s, and I also added an implementation of DirectX9 HLSL, really just for the hell of it.
I spent this evening getting the nvparse code _mental_ has been working on compiling under VC6 and VC7; basically this is to provide support for ps_1_x equivalents under GL for nVidia cards, since GL’s first standard was equivalent to ps_2_0 which cards like the GeForce3 and GeForce4 do not support. nvparse produces the effect of using NV_register_combiners and NV_texture_shader, and the best thing is that you can generate it from Cg.