Some free time to spare..

Engines, Libraries and Tools Xith3D Forums
#1

I think it’s rather rare for a project to be offered a programmer. I had some projects I was the manager of and I would have appreciated someone to offer his help. That’s what I’m doing there.

Here’s a little detail about the options above :
1 : Joomla! is much nicer from a design point of view, and I know pretty well its administration. We can do a lot more things with it than with tiki-wiki. The only problem IMHO is that it’s may not be as lightweight as tiki-wiki. More infos : http://www.joomla.org/
2 : Some infos are not relevant anymore : about xith mailing list, e.g. and the structure of the site seems not so logical. Some pages would benefit to be splitted, and some info to be regrouped. I think I can take care of it.
3 : Improve Xith’s visibility, and makes a bit of advertising ;D
4 : Some users were complaining about the lack of javadoc
5 : Collision detection isn’t really used. I have to study sound support. By the way, do YOU use it ?
6 : Many little things to improve
7 : Could be useful, have to work with Croft (have done some work in this direction)
8 : Collada is ideal for game developers. I think the Blender+Xith+Joode+FengGUI+JInput+Eclipse+BeanShell is a must for a game developer. And for Blender-Xith interaction we need a format like COLLADA.
9 : That’s more of a joke, but anyway could be useful to bring more fresh blood into Xith.
10 : More practical for users.

#2

Great news !

I think writing correct javadoc (with lots of cross refs) would be great.

Also separating the unfinished/buggy parts of with wouldn’t be necessary if javadocs clearly stated not to use them (until they’re fixed).

Let’s see now what other users think of your proposal …

Lilian

#3

implementing the compile() method would be nice :-*

#4

[quote="<MagicSpark.org [ BlueSky ]>,post:1,topic:26577"]
8 : Collada is ideal for game developers. I think the Blender+Xith+Joode+FengGUI+JInput+Eclipse+BeanShell is a must for a game developer. And for Blender-Xith interaction we need a format like COLLADA.
[/quote]
as for the beanshell part i guess you mean scripting? has anyone tried groovy ( http://groovy.codehaus.org ) yet? i believe it’s just great … if you haven’t tried … do it now

#5

I would LOVE a shadow example…

Sound work ok for me…

#6

I would find some work on the Javadocs useful. As someone quite new to Xith it would give me
some good pointers for a few aspects of the project I am currently working on.

William

#7

Ahah. This is pretty easy for me to do, since often it’s only a matter of studying code source and/or asking questions on the forum. So it’s just info gathering.
But I think the Javadoc is great only to know what a class or a function is useful for, but we need a more detailed documentations on the different Xith parts (there’s a short example of what I think of in the first chapter of the Xith Getting Started Guide)

Well unfinished parts shouldn’t be released at all. Experimental maybe, but not unfinished. As for buggy parts, I think they are just abandoned, so why not suppress them.

#8

Maybe you’re just kidding, but I thought this was just keeped for Java3D-compliance. I think we could just remove it.

#9

as for the beanshell part i guess you mean scripting? has anyone tried groovy ( http://groovy.codehaus.org ) yet? i believe it’s just great … if you haven’t tried … do it now
[/quote]
Yeah I mean scripting. But that was my personal combination. You can use Netbeans, too ^^
Yes I tried Groovy (along with Jython) and yes it seemed cool. But here’s the advantages Beanshell have :

  • Java-syntax compliant so you can just compile when you passed the prototype phase. And you can try commands in real-time.
  • It passed JSR-274 : see the news on http://www.beanshell.org/ (but I just saw Groovy also had a JSR)

Anyway the Groovy-Beanshell debate is far away from finished : see http://blogs.zdnet.com/Burnette/?p=22.
And I’ll try both and choose.

#10

OK. Thanks.

Yeah, in fact the only xith app where I saw shadows was the MD2 loader demo. I looked at the source code and I just saw it was a RenderingOption to enable.

#11

The five more rated items will make my TODO-list.
For now, here are the most popular :

  1. Write tutorial on COLLADA loading, and spread the info a new format is on the way!
  2. Clean & reorganize Xith WEB pages
  3. Add a list of Xith projects, with screenshots
  4. Clean up and javadoc all Xith functionalities
  5. Fix orthographic and technic mistakes in Xith Getting Started guide
#12

[quote="<MagicSpark.org [ BlueSky ]>,post:8,topic:26577"]

Maybe you’re just kidding, but I thought this was just keeped for Java3D-compliance. I think we could just remove it.
[/quote]
I thought Xith did everything with vertex-arrays behind the scenes. compile() could turn the static geometry into display-lists, VBOs and what-not-s.

But as Xith seem to have dropped the capability-bits, it’s kinda hard to determine whether a geometry is static or not. (CRC it once in a while? ;))

#13

[quote]ava-syntax compliant so you can just compile when you passed the prototype phase. And you can try commands in real-time.
[/quote]
groovy uses java syntax ( although with some limitations, for example classical for loops where succeded by for ( stuff in array ) type constructs )
so in most cases compiling with a standard java compiler works … in all other cases groovy comes with it’s own compiler which compiles groovy source to java bytecode
additionally groovy features a shell similiar to beanshell, but imho the beanshell shell is better

[quote]It passed JSR-274 : see the news on http://www.beanshell.org/ (but I just saw Groovy also had a JSR)
[/quote]
yep … groovy aims for a jsr ( http://www.jcp.org/en/jsr/detail?id=241 )

( i’m not trying to convince anyone to use groovy and no i don’t get money for advertising :wink: i just like groovy )

#14

I thought Xith did everything with vertex-arrays behind the scenes. compile() could turn the static geometry into display-lists, VBOs and what-not-s.

But as Xith seem to have dropped the capability-bits, it’s kinda hard to determine whether a geometry is static or not. (CRC it once in a while? ;))
[/quote]
Probably Yuri or Will can give more infos about that. I’m not (yet) a Xith guru.

#15

Hi,

[quote]implementing the compile() method would be nice
[/quote]
Makes no sense.

Due to inherently dynamic nature of current scenes (animated nearly everything), we don’t use display lists. VBOs are used automatically (OK, there is a minor bug in VBO implementation, so we should track it down and fix against latest drivers).

For VBO and other on-the-card caching, we have GeometryCacheType and set*CacheType for every individual component, so it is possible to say "Geometry is static, and Texture coords are animated).

If cache type is auto, renderer switches to use VBO after few frames automatically.

It is possible to implement also Display Lists - it is only change on Renderer level and 100% isolated from Scenegraph itself.

Yuri

#16

This VBO, video card, stuff is new to me so if the question I have is stupid…what the heck.

Are you basically saying we can set some of the scene “static”…how, what method.

Are you also saying that even if unset after a few cycles it is treated as static??

Much of the scenary in my game is static…rooms, wallm floors. If I can optimize this life would be better.

#17

Hi,

[quote]Are you basically saying we can set some of the scene “static”…how, what method.
[/quote]
YES.

com.xith3d.render.GeometryCacheType


/**
 * This class is used to define the policy used by the renderer to cache geometry information
 * on the card.  This can increase rendering speed by an incredible amount if the card
 * supports the geometry caching feature.
 * <p>
 * Caching is defined at the component level of a geometry array.  Thus color, texcoords,
 * normals and coordinates can be flagged with different policies.
 */
---
     * AUTO cache policy means that the renderer will attempt to detect dynamically if the
     * component is changing slowely enough to warrent caching the information on the
     * card.
---
    /**
     * NEVER cache policy means that the renderer will never attempt to cache the
     * component on the card.  This is mostly used for highly dynamic geometry like
     * particle systems to reduce the checking overhead that AUTO would entail.
     */
---
    /**
     * ALWAYS cache policy means that the renderer will always cache the geometry on the
     * card if possible.  This is mostly used for completely static geometry like models
     * to reduce the checking overhead that AUTO would entail.
     */

To set, use for example, IndexedTriangleArray.setNormalsCacheType(GeometryCacheType.ALWAYS):


     * Sets the cache type for the normal component of the geometry.  If the
     * normals will be changing frequently then this should be set to NEVER

[quote]Are you also saying that even if unset after a few cycles it is treated as static??
[/quote]
YES. And this is JavaDoc’ed from the very beginning…

But most people have VBOs disabled I guess (while it is enabled by default). Read http://www.java-gaming.org/forums/index.php?topic=2589.0 (discussed long time ago, in 2003)… Dirvers changed A LOT since that time…

Yuri

P.S. PLEASE PLEASE PLEASE! If you play with these and other features, please create a short example, which we with a great pleasure put in Xith3D Example Suite (when it will be created), so other people will not stuck on the same point as we are - lets share the knowledge!