Question in the title ;D
Well… depending on the goals.
I would like to see all rendering-related nodes & modes implemented before announcing 1.0 (maybe without behaviors, because of I see them as separate package, i.e. part of “scenegraph creation and manipulation utilites”), as well as some extra features. So, we have a kind of list:
- PointAttributes (+NV/ARB_point_sprite)
- Multipass Rendering (+RenderToTexture and Stereo Rendering)
- Testing.
- Examples.
- Testing.
- Testing.
- Testing.
[I know I forgot a lot of points].
My idea is that we should make a list of Java3D functionality/nodes/modes and check what we are missing, what we can leave out, and what we want to add. Then we will see how far we are from 1.0.
…but… do we need any 1.0, or we just need stable code? Yes, 1.0 sounds more stable than, say, 0.95, but what we mean by stable version then?
Yuri
I would like , off the top of my head
an extened set of demos showing some of the less explored parts of xith3d., such as a shadow example, use of the perlin stuff in utility.noise or the interpolator package. I am sure other people have other ideas
It wopuld be nice to have a small tool to run, examine your hardware and identify any apects of xith3d that are unsupportable, version of opengl your are running, shiould javadude vertex stuff work on your machine.
Get a set of people to commit to clean pulls, builds, and examine every demo for oddities
add a class to allow demo writers to say “I work with version 1.5 and greater” and query a users xith3d installation for what version it is, outputing version confilcts if needed.
I personally get lost some times as people provide examples etc that use xith3d and their stuff, don’t know how when some of what they have done may be added to the system. Perhaps setting up a xith3d-alpha extension mechanism (like the xithtk) for people to contribute, vertex shaderes, particle systems, heightfield generates etc. Then let other say that they are using X and would like it added to the system, if enough people use the Hawkwind Hieghtfield generator and are willing to post about hten maybe it should be added to the main system.
apart from anything else, we have to be 100% happy with the API too.
Once we hit 1.0 we really need to tell people that it will be backward compatable which is a restriction on how much we can tinker with it.
Will.
hear hear…well stated. Xith3D needs to insure backward compatibility for anything other than a compelling technical reason. In such a case mind numbing discussions and prominent statements in the Xith3d.org site will be required.
An additional suggestion would be to run the code through eclipse removing unsed variables and expanding import package.* to package.class. Also format the code in a consistent manner if its not already.
Any non functioning or empty methods should generate some message identify it is currently unsupported.
Fog
3ds using shadows properly
test
test
test
no 1.0 3D engine w/o fog of course.
Sound should be complete.
The basic 3D features should be present and working reliably (thats what Java3D is). Shaders and stuff are optional IMHO.
Maybe (not sure) some sourcecode cleanup? Split into core API, renderers, utilities (loaders,terrain,gui), tests and samples?
whats up with sound?
e.g. setRateScaleFactor() should do something.
We need it to pitch engine sound.
Javadoc is incomplete. I remember a lot of people had problems with terrain, userinterface etc. That’s mainly because these packages are hardly documented. People spend days just to find out how something works. From the perspective of a new developer I’d expect a 1.0 release to have good documentation.
Will mentioned the most important point: All 1.x releases have to backwards compatible with 1.0. We have to be happy with the interfaces. To ensure this we probably need LWJGL support in a proof-of-concept state.
Besides these points we can already introduce a versioning system. Currently we have an ALPHA_X system. We could call the current version 0.x.y (choose x and y as you like) and then define goals for every version step towards a 1.0 release. This would be some kind of a small roadmap.
Is Xith really anywhere near 1.0?
It might be near a formal release but its still quite early on isn’t it for a 1.0?
Kev
[quote]It might be near a formal release but its still quite early on isn’t it for a 1.0?
[/quote]
Agree.
Yuri
if it helps, I could try to list which features available in Java3D are still missing in order to make FlyingGuns work?
Picking comes into mind…
But yes, maybe a 1.0 consideration is too early.
Looking forward to LWJGL support - I want to start playing with 3D again.
Cas 
[quote]Picking comes into mind…
[/quote]
Xith3D has picking implemented with SELECT rendering mode. Does FlyingGuns use something specific in picking which can not be achieved with implemented mode?
Yuri
[quote]Javadoc is incomplete. I remember a lot of people had problems with terrain, userinterface etc. That’s mainly because these packages are hardly documented. People spend days just to find out how something works. From the perspective of a new developer I’d expect a 1.0 release to have good documentation.
[/quote]
Yes, Javadoc is nearly missing. Several times you can use the Java3d Docu instead, but not always. Due to this fact many questions are being posted here in the forum (I am one of these) and a few Xith developers try their best to answer (which stops them from working on Xith…).
Should we build a “Xith Javadoc task force”?
I think while special effects in Xith are nice to see they’re not important for a v1.00 release. Stability and other important things (several have been mentioned here) should have priority, so that Xith v1.00 will be a round (how to say in English?) thing.
I’d love to see a Xith3d loader interface for example. Not only to use the loaders in a standard way, but also when it comes to animation of these loaded models: this should always work the same way, no matter which 3d model format you’ve loaded. Or take the situation where you want to manipulate some of the (Transform) “groups” of the model. Etc.
[quote]I’d love to see a Xith3d loader interface for example. Not only to use the loaders in a standard way, but also when it comes to animation of these loaded models: this should always work the same way, no matter which 3d model format you’ve loaded. Or take the situation where you want to manipulate some of the (Transform) “groups” of the model. Etc.
[/quote]
This is not always possible. Most generic loader returns BranchGroup - that’s all. Loaders can name nodes, attach custom userData to them, and also they are free to use own loader-specific implementations of nodes to properly fit to the format.
As of animations, there are A LOT of different methods of animations, and this is for what Java3D behaviors (interpolators) were introduced. I see most generic way for loader is to return a list of named Alpha objects, so application can control the animation without even knowing the details of loaded scenegraph.
Yuri
BranchGroups are OK for my intended manipulation purposes. However, what would be nice, if these generic loaders would allow me to fetch them in the same way (say the ASE loader and the 3DS loader …).
[quote]As of animations, there are A LOT of different methods of animations, and this is for what Java3D behaviors (interpolators) were introduced. I see most generic way for loader is to return a list of named Alpha objects, so application can control the animation without even knowing the details of loaded scenegraph.
[/quote]
That’s good to hear. While in the Xith3d docu there’s some mention of Behaviours, are they already there in way comparable to Java3d?
Something along these lines has to happen. We could do the following steps (already talked with Will about this, but I had no time to do something useful):
- agree on code conventions
- file “missing documentation” issues to certain Xith3D subpackages
- use the BTS to document the progress of commenting these classes (Is there some way to run Javadoc that it complains about every not document public element?)
- hope that new commits include Javadoc
We don’t only have to make sure, that there is some documentation, but it also has to be good. This is a major problem, because there are probably some parts of Xith3D, where only David knows how they work. I’d really liked to hear David’s and Yuri’s opionion about this. In fact I already wanted to contact them some weeks ago, but for the last seven weeks and until next week I have/had exams.
Too bad that the decompiler didn’t generate the comments