Personally I think it is good API design to keep the core small and have optional modules that people can use or not (so long as each of the modules list their dependancies clearly). This also provides some QA - commits to the core can be more heavily scrutinised.

It would be good to support JOODE for Physics/Collision when that is usable (not sure if it is or not - havn't checked for a while).

Personally I think it is good API design to keep the core small and have optional modules that people can use or not (so long as each of the modules list their dependancies clearly).

I agree. But let's stay with the loaders as an example. Wouldn't it be logic to put the loader-bases into the core (as it was once for a short time, if I remember right)? Model loaders belong to a 3D lib like texture loaders do. But it wouldn't make sence to put all the loader implementations into the core, but the basis for any impl is a thing for the core, isn't it?

Having just downloaded the latest core/toolkit code I kinda consider the separation to be artificial. Develoers come and go within Xith and I really am not sure if the separation helps or is required. In general I would like the whole set in a single tree.

I would be interested in seeing the Xith Nutshell doc.

I have a Javacooldude shadow example in Java3D. Pretty cool stuff. I have been messing with it trying to make it Xith 3d compatible but don't have anything working. I could post the code if someone else wanted a go at it.

Having just downloaded the latest core/toolkit code I kinda consider the separation to be artificial. Develoers come and go within Xith and I really am not sure if the separation helps or is required. In general I would like the whole set in a single tree.

It certainly is artificial, but it absolutely makes sense. The core contains all parts, which are necessary for the library to work and the toolkit contains less important goodies, which are just nice tools to make the whole thing more comfortable and complete.

If you want it to be in one whole jar, you're free to create such a jar for your game distribution. This isn't a too hard job, is it?

@Qudus : loaders aren't meant to be in the core cause they do *use* core features, are big and you don't need all of them at once, and don't touch the core scenegraph features. I think they are very much at home in the core.

Hmm by the way, anyone interested with a Cal3D loader for Xith3D ? I guess I forgot to commit this one. And I have a system which pre-compute each frame and store it (if we implement display lists, this is gonna be fast as lightning !).

I don't see how JOODE can be supported more than it is actually : as I said precedently, JOODE devs uses Xith3D for tests...

@Qudus : loaders aren't meant to be in the core cause they do *use* core features, are big and you don't need all of them at once, and don't touch the core scenegraph features. I think they are very much at home in the core.

That's true. But I think the loader's base (Scene, SceneBase and all the stuff in org.xith3d.loaders.scene) are core features, because model loaders im common are an essential feature of any 3d engine, but the loader implementations themselfs arent't.

Hmm by the way, anyone interested with a Cal3D loader for Xith3D ? I guess I forgot to commit this one. And I have a system which pre-compute each frame and store it (if we implement display lists, this is gonna be fast as lightning !).

The Cal3D loader is mentioned in XIN as a supported feature. So I guess it should be present. I would love to see your code committed.

I don't see how JOODE can be supported more than it is actually : as I said precedently, JOODE devs uses Xith3D for tests...

The Node class has a flag called collidable. Flags like that should be reused for a physics abstraction.

I *don't* want to mix up graphics and physics. Qudus you should be careful not to do things in a too specific way (which works wll for you, but not necessarily everyone's cup of tea, cf. RenderLoop). Physics have to be bound to graphics by the user itself the way he/she wants to. Just my 3 cents.

I *don't* want to mix up graphics and physics. Physics have to be bound to graphics by the user itself the way he/she wants to. Just my 3 cents.

Maybe I have even less knowledge of physics than I thought So I don't know how to bind a physics engine to a scenegraph. I thought it was only linking shape nodes ang TransformGroups with Physics nodes and configuring the way they effect each others. The letter part certainly can't be "integrated" with xith, but the first one should.

Why is this CollisionSystem present in Xith-tk? Isn't this a minimalistic physics system? Isn't a physics system mixed up with our graphics lib?

Don't get me wrong. I can live with not integrating JOODE with xith, but isn't this what people will expect from a fully featured 3d engine: a graphics renderer handling input and physics (generally speaking)? I think there's a reason why SDL and libs like that have everything in one lib: People wan't it that way. I don't say we should hard-link joode with xith so that people won't have a change to choose their physics engine. But life should be made most easy for developers when they wan't to use a physics system with xith. And flags like isCollidable are disturbing whan they are present and don't do anything for me when I'm not using the integrated collision system, which I can't whan it's that basic (and broken).

As I said: I can live without this integration, but I think life would be easier, if we did it.

Qudus you should be careful not to do things in a too specific way (which works wll for you, but not necessarily everyone's cup of tea, cf. RenderLoop).

What's wrong with (Ext)RenderLoop? Isn't this what everyone needs? Every single example in the TK is built this way (and it was before I came to the project). So I just adepted what I found. I'm certainly open for any suggestions, what could be done better. But I really thought, it was what people need.

I *don't* want to mix up graphics and physics. Physics have to be bound to graphics by the user itself the way he/she wants to. Just my 3 cents.

Maybe I have even less knowledge of physics than I thought So I don't know how to bind a physics engine to a scenegraph. I thought it was only linking shape nodes ang TransformGroups with Physics nodes and configuring the way they effect each others. The letter part certainly can't be "integrated" with xith, but the first one should.

What we should have is an "? extends Animatable" class which takes a Body (JOODE) and a TransformGroup (Xith3D). And that would be just fine.

Qudus you should be careful not to do things in a too specific way (which works wll for you, but not necessarily everyone's cup of tea, cf. RenderLoop).

What's wrong with (Ext)RenderLoop? Isn't this what everyone needs? Every single example in the TK is built this way (and it was before I came to the project). So I just adepted what I found. I'm certainly open for any suggestions, what could be done better. But I really thought, it was what people need.

I just think we should not put in the scenegraph what doesn't belong to it. What if I want to use your ExtRenderLoop in something which doesn't use Xith3D ? Your code would be just fine it's just too tied to Xith3D.Now imagine your game has a menu.. how do you handle the transitions with RenderLoop ?

}[/quote]ShouldIusetwoRenderLoopsandswitchfromonetoanotherwhenneeded ? orhaveanenumwhichtellsmewetherI'm in the menu or not and have a Switch node containing the menu and the gameScene ? But in-game the menu is rendered in transparency, over the game.

So you see I'mnotdonewithallthesequestions. (Ohandthecodeisprobablyshittybutatleastitworksfine).

Should I use two RenderLoops and switch from one to another when needed ? or have an enum which tells me wether I'm in the menu or not and have a Switch node containing the menu and the gameScene ? But in-game the menu is rendered in transparency, over the game.

No. You can just use one. I don't see any problem with it. Please have a look at the RenderEngine interface and at the Intervall class system. The RenderLoop class takes an instance of RenderEngine for the method addRenderEngine(). The Xith3DEnvironment class implements this interface, so generally this instance is passed to the method. But you can also make your game class implement this interface and add it to the RenderLoop. Then you can easily make any call of env.render(gameTime, frameTime) in the interface's method.

The other possibility was to create an instance of Interval and pass it to the addInterval() method of the ExtRenderLoop. give the interval a value of 1000L and let it call your menu.update() method each second.

Or just override the loopIteration() method and put your main game loop code in there and update your menu each second.

There're several different possibilities for different flavors and you may decide to use any of them, can't you?

I just think we should not put in the scenegraph what doesn't belong to it. What if I want to use your ExtRenderLoop in something which doesn't use Xith3D ? Your code would be just fine it's just too tied to Xith3D.

The classes are tied to Xith3D but they have several interfaces which are implemented and wich aren't tied to any implementation of a scenegraph. So, yes of course the implementation is tied to Xith but you can easily use the interfaces and write an implementation for any other renderer.

What's up with the TODO list on xith.org? I can't edit it. Every time I try a message pops up saying: "The module [ToDo] is currently being edited by another person.", which is absolutely impossible, since I am the only member being logged in .

What's up with the TODO list on xith.org? I can't edit it. Every time I try a message pops up saying: "The module [ToDo] is currently being edited by another person.", which is absolutely impossible, since I am the only member being logged in .

I noticed this first yesterday evening / night.

Could you maybe have a look at it, Amos?

Hmm.. that's when someone (could be me, could be you) quit the page when editing a page without hitting the "cancel" button. It's now writeable again. (Next Time, In Admin, go to "System->Global Checking" and it's done !

Hmm.. that's when someone (could be me, could be you) quit the page when editing a page without hitting the "cancel" button. It's now writeable again. (Next Time, In Admin, go to "System->Global Checking" and it's done !

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org