This thread may serve as a discussion about the development plan, I’ve just released on xith.org.
The points on this list represent the goals for a stable version 1.0 of Xith3D (and Xith-TK).
Marvin
remark: It doesn’t need to be made sticky, since I’ve put a link to it above the list.
Good plan.
SVN is so much better than CVS.
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).
Cheers,
Will
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?
Strange typing error? Well I’ve fixed it and now (#7) on the dev plan is as it should have been --> including JOODE.
Good plan…
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.
william
How do you feel JOODE copares with the ODEJAVA work you have been involved in??? I am unable to access odejava.org due to bandwidth problems. Have you dropped support of odejava??
Good to see you again. You have been gone from this site for awhile. ;D
The current (unfinished) development version is available from CVS of xith-tk (/docs/xin).
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?
Marvin
@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…
[quote="<MagicSpark.org [ BlueSky ]>,post:8,topic:28283"]
@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.
[/quote]
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.
[quote="<MagicSpark.org [ BlueSky ]>,post:8,topic:28283"]
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 !).
[/quote]
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.
[quote="<MagicSpark.org [ BlueSky ]>,post:8,topic:28283"]
I don’t see how JOODE can be supported more than it is actually : as I said precedently, JOODE devs uses Xith3D for tests…
[/quote]
The Node class has a flag called collidable. Flags like that should be reused for a physics abstraction.
The Node class has a flag called collidable. Flags like that should be reused for a physics abstraction.
[/quote]
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.
[quote="<MagicSpark.org [ BlueSky ]>,post:10,topic:28283"]
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.
[/quote]
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.
[quote="<MagicSpark.org [ BlueSky ]>,post:10,topic:28283"]
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).
[/quote]
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.
EDIT: Wow… my reply sounds like I’m angry. Be asured, that I’m not.
btw: It’s hard to find a common sense when so few people are active in the forums and development. 
Qudus, please edit your message and add " 1.0" to the title.
Your goal was to obtain a stable and reliable API, isn’t it ? For 2.0 we can aim way higher.
Right ?
[quote="<MagicSpark.org [ BlueSky ]>,post:13,topic:28283"]
Qudus, please edit your message and add " 1.0" to the title.
Your goal was to obtain a stable and reliable API, isn’t it ? For 2.0 we can aim way higher.
Right ?
[/quote]
Agreed and done.
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.
[/quote]
What we should have is an “? extends Animatable” class which takes a Body (JOODE) and a TransformGroup (Xith3D). And that would be just fine.
Yes, and I think it should be removed, or at least extracted
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.
[/quote]
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 ?
Here’s my current app code :
LocalApp.java
public class LocalApp {
public static void main(final String[] args) {
final LocalApp app = new LocalApp();
app.run();
}
private World world;
private ExtXith3DEnvironment env;
private Group scene;
private IACode ia;
private UserCode userActions;
private AWTKeyboard keyboard;
private WorldRepresentation worldRepresentation;
private NPFCounter fpsCounter;
private PanelOverlay menuOverlay;
private boolean previousGame;
private Group gameScene = new Group();
private UIWindow mainOverlay;
private UIWindowManager gameWindowMgr;
private MainOverlayPanel mainOverlayPanel;
private int playTime;
private LoadingPanel loadingPanel;
// Testing
private final static int WIDTH = 800;
private final static int HEIGHT = 600;
public void run() {
TextureLoader.getInstance().getTexture("");
// Init 3D scene
env = new ExtXith3DEnvironment();
env.addCanvas(new Canvas3DWrapper(OpenGLLayer.JOGL,
LocalApp.WIDTH, LocalApp.HEIGHT, ColorDepth.B24,
DisplayMode.FULLSCREEN, "Stratagem - Local version"));
scene = new Group();
env.addChild(scene);
env.addChild(new Background(new Color3f(0f, 0f, 0f)));
// Keyboard
keyboard = new AWTKeyboard(env.getCanvasComponent());
// Optimizations all over the place, whooha !!!
env.getCanvas().get3DPeer().getRenderOptions().setOption(
Option.USE_LIGHTING, false);
env.getCanvas().get3DPeer().getRenderOptions().setOption(
Option.USE_SHADOWS, false);
// Init & load menus
menuOverlay = new PanelOverlay(env, 800, 600);
HashMap<String, Menu> menus = new HashMap<String, Menu>();
menus.put("MainMenu", new MainMenu());
menus.put("OptionsMenu", new OptionsMenu());
menus.put("GameOptionsMenu", new GameOptionsMenu());
menus.put("PlayMenu", new PlayMenu());
MenuCode menuCode = new MenuCode(env, new String[] { "MainMenu",
"OptionsMenu", "GameOptionsMenu", "GraphicsOptionsMenu",
"PlayMenu" });
String menu = "MainMenu";
newGame(new GameInfo("Commander1", "Commander 2"));
runGame();
// Menu loop
for (boolean isRunning = true; isRunning; Thread.yield()) {
Message msg = menuCode.launchMenu(menu);
if (msg.name.equals("action")) {
String action = (String) msg.args.get(0);
if (action.equals("play")) {
env.render();
if (!previousGame) {
newGame((GameInfo) msg.args.get(1));
}
runGame();
menu = "InGameMenu";
} else if (action.equals("resume")) {
runGame();
} else if (action.equals("abort")) {
env.removeChild(gameScene);
} else if (action.equals("exit")) {
isRunning = false;
}
}
}
Options.get().finalize();
// Exit
System.exit(0);
}
/**
*
*/
private void runGame() {
mainOverlay.setVisible(true);
long beginTime = System.currentTimeMillis();
long previousTime = System.currentTimeMillis();
for (boolean isRunning = true; isRunning; Thread.yield()) {
long delta = System.currentTimeMillis() - previousTime;
delta = Math.min(100, delta);
userActions.update(true, delta);
ia.step(delta);
previousTime = System.currentTimeMillis();
// Rendering
if (System.currentTimeMillis() - beginTime > 1000) {
playTime += 1;
beginTime += 1000;
mainOverlayPanel.update(playTime);
}
fpsCounter.update();
worldRepresentation.update(0, delta);
gameWindowMgr.newFrame(env.getView());
env.render();
if (!env.getCanvasComponent().isVisible() || userActions.shouldExit) {
userActions.shouldExit = false;
isRunning = false;
}
}
}
private void newGame(GameInfo gameInfo) {
if (loadingPanel == null) {
loadingPanel = new LoadingPanel(env, menuOverlay.getWindowManager());
menuOverlay.clear();
menuOverlay.displayCentered(loadingPanel);
}
playTime = 0;
loadingPanel.println("Creating terrain...");
// Add a terrain and its representation
final TerrainAttributes terrain = TerrainAttributes.get("TestTerrain.xml");
loadingPanel.println("Creating world...");
// World
world = new World(terrain);
loadingPanel.println("Adding armies...");
initArmies(gameInfo);
loadingPanel.println("Creating world representation...");
// Representation
gameScene = new Group();
worldRepresentation = new WorldRepresentation(world, gameScene, 1);
env.addChild(gameScene);
loadingPanel.println("Init user actions...");
// User actions
userActions = new UserCode(env, world, gameInfo.commander1Name,
keyboard, worldRepresentation, 1);
loadingPanel.println("Init IA...");
// IA
ia = new IACode(world);
// FPS & NPF counter
fpsCounter = new NPFCounter();
fpsCounter.setEnabled(false); // FIXME
loadingPanel.println("Creating overlay...");
// construct a window manager for this canvas
mainOverlayPanel = new MainOverlayPanel();
mainOverlayPanel.setGameInfo(gameInfo);
if (mainOverlay == null) {
mainOverlay = new UIWindow(mainOverlayPanel.getWidth(),
mainOverlayPanel.getHeight(), false, true);
gameWindowMgr = new UIWindowManager(env.getCanvas());
gameWindowMgr.addOverlay(mainOverlay);
gameWindowMgr.setPosition(mainOverlay, env.getCanvas().getWidth()
/ 2 - mainOverlay.getWidth() / 2, 0);
gameWindowMgr.setVisible(mainOverlay, true);
UIEventAdapter eventAdapter = new UIEventAdapter(gameWindowMgr);
Canvas3DWrapper canvas = (Canvas3DWrapper) env.getCanvas();
canvas.addKeyListener(eventAdapter);
canvas.addMouseListener(eventAdapter);
canvas.addMouseMotionListener(eventAdapter);
canvas.setFocusable(true);
gameScene.addChild(gameWindowMgr);
}
mainOverlay.setRoot(mainOverlayPanel);
previousGame = true;
menuOverlay.clear();
}
/**
* Initiate the armies
*
* @param gameInfo
*/
private void initArmies(GameInfo gameInfo) {
/*
* Army 1
*/
final String commander = gameInfo.commander1Name;
final Army army = new Army(commander, new Color3f(1f, 0f, 0f));
world.addArmy(army.getCommanderName(), army);
final float xCenter = world.getTerrain().getSizeX() / 2f;
// Add fantassins
UnitUtils.addUnits(army, 8, 8, 1f, new Vector2f(xCenter, 35f), 0.1f,
"Fantassin.xml");
/*
* Army 2
*/
final String commander2 = gameInfo.commander2Name;
final Army army2 = new Army(commander2, new Color3f(0f, 1f, 0f));
world.addArmy(army2.getCommanderName(), army2);
}
}
[/quote]
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.
So you see I'm not done with all these questions. (Oh and the code is probably shitty but at least it works fine).
[quote="<MagicSpark.org [ BlueSky ]>,post:15,topic:28283"]
private ExtXith3DEnvironment env;
[/quote]
If you’re not using ExtRenderLoop or in your case not even RenderLoop it is sufficient to use Xith3DEnvironment instead of ExtXith3DEnvironment.
[quote="<MagicSpark.org [ BlueSky ]>,post:15,topic:28283"]
env.getCanvas().get3DPeer().getRenderOptions().setOption(
Option.USE_LIGHTING, false);
env.getCanvas().get3DPeer().getRenderOptions().setOption(
Option.USE_SHADOWS, false);
[/quote]
this can be done easier:
Canvas3DWrapper c3d = (Canvas3DWrapper)env.getCanvas();
c3d.setRenderOption(Option.USE_LIGHTING, false);
c3d.setRenderOption(Option.USE_SHADOWS, false);
or
env.disableLighting();
[quote="<MagicSpark.org [ BlueSky ]>,post:15,topic:28283"]
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.
[/quote]
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?
[quote="<MagicSpark.org [ BlueSky ]>,post:15,topic:28283"]
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.
[/quote]
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.
Marvin
OK, designed better than I thought ;D
Will take a look at it (if it makes my code more concise it’s welcome).
It seems that my OpenOffice.org 2 is no longer crashing when trying to insert an image / save a file. Great ! I’ll be able to finish XIN.
Good to know :).
When you’re ready I’ll add two additional chapters documenting multipass rendering and scenegraph traversal. Then we can finally release it ;D.
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?
Marvin