Hi,
Can anybody of developers currently working on Xith3D core make a short summary of the changes, so I can coordinate my changes with the current version of Xith3D?
Is the current CVS version more or less stable?
Yuri
I’ll sum them up the next days when I find some time for it.
I guess it is a little less stable at the moment, since I made some really huge changes. But I’m debugging, so it will be stable in some days (I hope). But it’s not too unstable. And If you’d use it, we could find bug faster.
Marvin
Hi,
I anyway have ~200,000+ lines of source code based on previous version of Xith3D, so I plan a switch to the latest CVS now.
Yuri
Cool.
@Yuri : I’ll try to summarize a bit :
Qudus made deep change to the rendering code so old known bugs may have disappeared while new one are being killed each day (even if not reported here).
About groups : BranchGroup is now used exclusively for Locales. For everything else you should simply use Group.
Some classes have been moved (e.g. Canvas3D from scenegraph to render IIRC) in fact they’ve been copied and set to deprecated in their previous location…
Now Shape3D have “Types” with the setType() method you can specify if your shape is entirely dynamic, entirely static or if only the appearance or only the geometry are static. This is used AFAIK to build display lists.
Low-level multipass rendering has been implemented. For more details, ask to Qudus.
RenderLoop/ExtRenderLoop and Xith3DEnvironment/ExtXith3DEnvironment are slowly becoming adopted by Xith3D users. They contain utility functions, e.g. for thread-safe operations (with ScheduledOperator), timing facilities, and tons of others things (just browse the code).
I’ve added a PrecomputedAnimatedModel class with 2 loaders : from OBJ animations as exported by blender and for Cal3D animation (the Cal3D loader has been ported by me from theKman’s work for jME).
Other various notes about community/dev :
- We’re (I for now) progressively writing the W3G book (Writing 3D Games with xith). Currently I have written a small example which shows several interesting aspects of optimizations which can be made. You can have a look at it, it’s well-documented (@see org.xith3d.w3g.ColorCube).
- A blog space has been opened on Xith.org (http://www.xith.org/dev_blog/) I would be glad if you (and Qudus, by the way) can post what you’re doing on Xith here so all of we can follow it more easily. Register on xith.org if not done and I’ll grant you write access.
A little typing error here, which messes up the sense. BranchGroups are exclusively for being added to Locales.
Canvas3D is not copied. It is moved to com.xith3d.render and a I’ve created a new class with the same name in the scenegraph package, that extends the one in render and which is deprecated. So the old code is compatible in this regard.
That’s correct. Additionally you can set the type through the Shape3D constructor.
I think XIN helped to publish the information about these class’es existance.
Marvin
EDIT: btw. Qudus = Me
Edited the previous message, I really meant “now Bgs are used for…”, not “not” ^^
Huh always regarding about credits, hehe ? ^^ No just kidding so I should always call you Marvin from now on ?
I do already. You’re the only one, who still calls me Qudus ;D.
Marvin
Hi,
[quote]About groups : BranchGroup is now used exclusively for Locales. For everything else you should simply use Group.
[/quote]
Oops… Breaks compatibility with my code a lot - I use BG for logical grouping and attaching meta information to the subgraphs…
Sure not so big change, but in this case compiler does not warn me “class not existing”…
Yuri
Oops… Breaks compatibility with my code a lot - I use BG for logical grouping and attaching meta information to the subgraphs…
Sure not so big change, but in this case compiler does not warn me “class not existing”…
Yuri
[/quote]
Well then you just have to create a GroupBranch class or somewhat, and replaces instances of “org.xith3d.scenegraph.BranchGroup” in your code with “this.is.your.package.GroupBranch” then replace all “BranchGroup” with “GroupBranch” (thus avoiding package problems)… With eclipse it’s done in a few minutes.
Just for the sake of curiosity, what are your ~200’000 code lines about ? 
First off I have become a big proponent of the recent changes made to some of Xith. I am slowly converting from my swing-xith UI to the HUD and am very pleased with the ease of conversion and the quality of the HUD UI components.
These are GREAT improvements…my code is becoming much clearer as I fail over to using these routines.
Run and examine org.xith3d.test.ui.HUD3DTest
The Texture loader stuff is different, see an example using the class Xith3DDemoFolder in the HUD3DTest.
Amos, check your PM.
As of replacing, sure it is no problems, but I have to convert also other my developers involved… so this is more organizational question than technical.
Yuri
Ah yeah, so obvious to me now that I forgot to mention it.
Yuri if you have seen TextureLoader2, then it’s now named TextureLoader and the Old texture loader has been completely removed. So now we don’t depend anymore on com.sun packages at all.
Yeah, I see.
EDIT: That’s where it’d been useful if you had creeped on these forums while you were working with Xith3D : surely design decisions are made taking into account users’ opinion/work.
Hi,
[quote]Yuri if you have seen TextureLoader2, then it’s now named TextureLoader and the Old texture loader has been completely removed.
[/quote]
I am not dependent on TextureLoader at all - I use my own texture loading mechanism which loads images DIRECTLY into DirectBufferedImage instead of loading to BufferedImage and after converting to elementary array - this significantly reduces memory consumption during application startup, and sometimes speeds up application startup, too.
Yuri
I am not dependent on TextureLoader at all - I use my own texture loading mechanism which loads images DIRECTLY into DirectBufferedImage instead of loading to BufferedImage and after converting to elementary array - this significantly reduces memory consumption during application startup, and sometimes speeds up application startup, too.
[/quote]
OH man! Would you contribute that to xith-tk? This feature has been asked for a few days ago.
Hi,
Something like this:
public static final Texture2D setupRGBATexture(String resource, int sizeLimit, int boundaryWidth)
{
BufferedImage bi = null;
boolean noUpscaleNeeded = false;
try
{
ImageInputStream stream = ImageIO.createImageInputStream(J3D2Utils.class.getResourceAsStream(resource));
Iterator iter = ImageIO.getImageReaders(stream);
if (iter.hasNext())
{
ImageReader reader = (ImageReader)iter.next();
ImageReadParam param = reader.getDefaultReadParam();
reader.setInput(stream, true, true);
int iw = reader.getWidth(0);
int ih = reader.getHeight(0);
int piw = pow2(iw);
int pih = pow2(ih);
if ((iw == piw) && (ih == pih))
{
BufferedImage dst = DirectBufferedImage.getDirectImageRGBA(piw, pih);
param.setDestination(dst);
}
bi = reader.read(0, param);
stream.close();
reader.dispose();
if (sizeLimit > 0)
{
if ((piw <= sizeLimit) && (pih <= sizeLimit))
noUpscaleNeeded = true;
}
else
noUpscaleNeeded = true;
}
else
stream.close();
}
catch (Exception e)
{
System.err.println("Error loading " + resource);
e.printStackTrace();
}
BufferedImage bimg1;
if ((bi instanceof DirectBufferedImage) && noUpscaleNeeded)
bimg1 = bi;
else
bimg1 = upScaleRGBA(bi, sizeLimit);
ImageComponent2D imgc1 = new ImageComponent2D(ImageComponent.RGBA, bimg1.getWidth(), bimg1.getHeight(), bimg1);
return setupRGBATexture(imgc1, boundaryWidth);
}
upScale and setupRGBATexture methods are trivial, you nayway do not need them (OK, maybe upscale) in your architecture.
Important point is param.setDestination(dst), so you theoretically can modify your existing TextureLoader2 to use this trick, so everybody will immediately benefit from it.
I can not contribute to your loader because of my texture loading architecture is quite different and quite project specific.
Yuri
Huh okay, will see what I can do.
Hi,
Shader processing seem to work somehow strange. I checked older examples (especially, TextureFiltersTest and StencilTest), and they do not work as expected.
Check JavaWebStart versions on xith.org - there they work as expected (Hit “Space” in StencilTest to see the difference with stencil test on/off).
Also the Q3FlightBenchmark shows in some cases odd behavior which is from my experience is typical when ther is a problem with shaders state changes.
Yuri