On Thu, Apr 13, 2006 at 01:12:59PM +0200, Jiba wrote:
> > You can use this function to set land materials using either a greyscale or
> > indexed image. I've tested it with several dozen materials.
>
> I've included these two patches in CVS.
Thanks Jiba
Feedback on the Cal3d Morph-Target support?
I have a growing list, and unfortunetly, more cash than time at this point with
this new business. I'm thus defining a list of tasks which need to be done in
short order (much of which are Soya3d enhancements or bugfixes) and assigning
either bounties or direct contracts to get them completed.
Part of this list is estimating each item's difficulty and likely time to
complete,
so I'd like feedback from everyone who've worked with Soya code recently on
these:
1) Cal3d Morph Targets/Animation
* support seems to be in cal3d already
* exporter script may need some work for this
2) Bump-Mapped Materials (Normals would be a later extension of this)
* materials need to support more than one texture
* needs to be backwards-compatable to the older API
* I believe that setting some things as "depreciated" should be ok
* should be extensible for additional texture types
* renderer needs to ignore texture layers beyond card's capabilities
3) Solid Translucent Objects (aka volumetric "fog")
* for water, ground mist, nebula, glass walls, etc
* there's already a section in the renderer reserved for the watercube..
4) 2d Wave Module (for water surface mesh deformation from wind, boats, etc)
* Fairly basic calculations
* Fast when done in C/Pyrex
5) Better Sound/Music Integration
* neither OpenAL or SDL_Mixer are good solutions by themselves
* should support Vorbis, Speex, FLAC, and .wav
* both streamed and file support
* sound effects need to be pre-loadable
* OpenAL's doppler effect should be retained/copied
* track status, seek, and crossfade support
* playing just a clip of a longer track for sound fx
* all core processing must be in C/Pyrex for speed/latency
* must remain multithreaded for low latency
* old API must be supported (even if depreciated)
I know there's some things missing/broken in the ODE bindings (such as
ODE + Cal3d integration), Cal3d model posing (beside animations), and the
exporters need a bit more TLC as well. These are not issues effecting my
immediate game-dev needs, however, but they should be defined as well.
I believe we should adopt the standard "odd minor versions are development"
mode. This means bugfixes get applied to 0.10 (prehaps for 0.10.3) and a
seperate tree for 0.11.x working toward a stable, well tested 0.12 release.
Part of getting the next stable release out is building a roadmap of features
that are currently missing (and needed), too slow, or not working properly.
I also believe that Soya is "almost there" and that a 1.0 release will do it
much good. 0.x implies Alpha, and it's definetly beyond Alpha at this point.
We need better documentation (ie, a User Guide and API reference included),
testing on more hardware (I've recently found 2 popular cards which segfault
under certain conditions in Soya), and some API cleanups before 1.0 release.
_______________________________________________
Soya-user mailing list
[email protected]
https://mail.gna.org/listinfo/soya-user
