Merge Java3D and Xith3D?

Engines, Libraries and Tools Xith3D Forums
#21

One final thought re: users.

Most of the j3d games submitted to JGF are “the last thing I’m ever doing with j3d” and often accompanied by “and I’m not going to update or maintain it ever”.

I tend to interrogate submitters of j3d games quite a lot, first because of the problems of getting webstart with j3d, and nowadays just because of the problems of getting j3d games to run, period.

It seems that most only stick with j3d for a single project, and by the end they’re pretty open-minded towards xith, jme, etc (although many more have heard of xith than have heard of jme). I tend to give them a shunt in the direction of the JGF techs page, and encourage them to evaluate each of the techs there, suggesting that j3d is far from the best of them ;D.

Although…there’s a lot of suspicion of Xith still around. And ignorance of jME. I think Xith needs to get a couple of major projects appearing on sun.com / java.com sites as showcase games, i.e. on their news section, to blast away the suspicion.

And jME just needs more press ;).

#22

I read on java.sun.com that sun employed an experienced 3d team working with ogl and things like that for j3d.
I can take a look at the article and maybe post the address to it here.

Alonzo

#23

There are still quite a few Sciviz projects running over the top of Java3D. One of the biggest reasons for this is the large amount of file loader support. The people that use it, want to just get stuff done and not have to worry about file parsing issues for 10 different formats. The other factor keeping them there the ability to run on multiple-CPU machines with no need to recode the application. With its architecture, it can transparently scale the amount of internal processing to the amount of CPU resources available, which is something Xith3D cannot do, and from stated intentions, has no interest in doing. Thus our reason for starting the Aviatrix3D project.

One of the reasons we found that was not a feature for staying with Java3D is the “multithreaded access” to the API. If you wanted to not have visual issues then you needed for force everything into a single thread through the use of a single behaviour, and then use the behaviour to marshal all your application code into a single set of calls to Java3D. The ability to just arbitrarily write at any time was actually a negative issue in the end as developers learnt the hard way that that ability is actually really bad. You’ll notice that both Xith3D and AV3D both only allow you to write during a single set of callbacks to user code, in order to maintain synchronised rendering structures.

I believe that as soon as there is a reasonably complete, and viable alternative to Java3D in the high-end community, that almost everyone will depart for that project. There’s one group doing bindings for OpenSceneGraph, which is most likely to be the one that gets the big movement. I doubt our AV3D project will have a large user base for many years to come. We don’t promote it at all. The only real users are those that use it courtesy of its inclusion in Xj3D. Xith3D has a development goal of being single-threaded, so that’s not going to endear it to that crowd either and others such as LWJGL and jME have fundamental design problems that prevent them being used anywhere other than niche gaming markets.

Edit: FWIW, I’m actually interested in adding a Xith3D renderer to Xj3D as well, but it’s not a high priority right now. I’m wanting to see how it goes in a performance shootout as much as anything else. There’s a large, well-established codebase, so the overheads are known and the same for all renderers.

#24

[quote]And jME just needs more press
[/quote]
jME needs to work on the Macintosh. I figured out to fix it, uploaded example code on how to fix it, came back 6 months later and it was still completely broken.

[quote] LWJGL and jME have fundamental design problems that prevent them being used anywhere other than niche gaming markets
[/quote]
The biggest problem I’ve been having in this regard is anytime I suggest or ask a question involving my project, the first retort is always “Why in the world would you EVER need that in a GAME?” Answers to questions are usually in the context of “Well, you don’t use that code anywhere except when you shoot your sniper rifle, so it’s not important”. So people’s interest, and therefore willingness to answer questions or add engine support, for anything non-game related is virtually zero.

Which basically means if you’re not making a game, your choice is either Java3D or you’re on your own to figure it out.

#25

Good :slight_smile: The more these APIs focus on doing what they’re meant to do, the better they will be at it :smiley:

Cas :slight_smile:

#26

Not so good when people look at 3D in Java and only see it for making games, and those of us doing serious stuff move on to something else instead. Hardly the ultimate programming platform evangelized by some, if that’s the best Java can offer.

Funny how some will say that 3D Java will never be taken seriously until somebody makes a good game, but on the other hand, 3D Java will never be taken seriously if it can only make games.

#27

Last check, jME supported mac just as much as LWJGL does. There were problems with loading image formats with awt, but there are ways around that. If you posted your problem and your fix on the forums, I’m sure it would be well recieved.

I don’t know what you’re refering to about the "“Why in the world would you EVER need that in a GAME?” but usually if many people are questioning your design they have a valid point.

The design of jME is based on the design of a really smart person. Not to say he’s perfect, but “fundamental design flaws” is debatable at the least.

That said, Java3d just isn’t ment to do the same task as Xith3d so merging wouldn’t make sense. As far as the various other projects that work on LWJGL or JOGL (xith for example), different people like their code to look different ways. For example, I like the RenderState setup of jME.

I say “free” projects are about fun, so let people just do what’s fun to them. And I agree with Cas: API focus is a good thing.

#28

[quote]Not so good when people look at 3D in Java and only see it for making games, and those of us doing serious stuff move on to something else instead. Hardly the ultimate programming platform evangelized by some, if that’s the best Java can offer.
[/quote]
Whilst I sympathise with you, Jeramie, I have to agree with Cas. If Xith (or jME) were a Sun effort, heck even if they were heavily supported and promoted by Sun, but otherwise unaffilliated, then you would have a leg to stand on.

As it is, you’re pissed because Sun has dropped the ball when it comes to 3D graphics (or should I say “dropped the bomb”?) by a stunning failure to grasp even the basics of their own markets - but that’s hardly unusual (Sun is good at making those kinds of mistakes with java - and only time will tell whether the executive reshuffles of this year will result in the organization making fewer such stupid mistakes). Xith etc have picked up the pieces for games developers and make no secrets about this.

That said…I felt much the same way as you when people first suggested JOGL should “only” be used for games. I was using it for non-games apps and not-only was JOGL Sun-sponsored but it was also the only true low-level binding to OGL, and headed for being the ref implementation (or a large part of it) for OGL-in-java (sometime this decade). So…I empathise. However…with Xtih etc it’s very different because these are building high-level libraries in pure java code on top of the low-level bindings - i.e. you could replace them with an entire stack built on the same bindings but with your replacement code using only java code. That wasn’t an option for people needing OGL - the alternative was to do as LWJGL and get out the C compiler.

That’s why I sympathise with you but don’t wish it were any different: Xith etc are non-Sun, high-level API’s which you could relatively easily replace. As Cas pointed out, their focus on games is a commendable thing, ensuring that they are a solution for a problem, rather than a solution looking to take on all-comers, and ending up being mediocre at everything (um, Java3D, anyone? [sorry, couldn’t resist]).

3D java is already being taken seriously -just by games developers. Go and look at the reception that MegaCorps Online is getting. Heck, I’d even be willing to believe that that positive press is going to rub-off on non-games people if it comes onto their radar (e.g. being highlighted on opengl.org might sneak it in ;)).

Personally I’m highly amused that it’s ended up that general 3D devs now have to come crawling (no offence intended!) to games-devs who are sitting on the only decent 3D java techs around. A far cry from the days where games devs were weeping because java3D was so near yet so incredibly far from being of any use at all.

PS: …and that changed only because of Java 1.4. Repeat after me “Thank you NIO! NIO you are salvation!” (modulo the great work of people who actually made use of it, of course :))

PPS: Couldn’t sleep. Caffeine withdrawal. Um. I think I’ve gone too far the other way…

#29

[quote]Last check, jME supported mac just as much as LWJGL does. There were problems with loading image formats with awt, but there are ways around that. If you posted your problem and your fix on the forums, I’m sure it would be well recieved
[/quote]
I already did, months ago. I said you had to disable the opening options dialog box, because any usage of AWT/Swing completely screws up the JVM for any usage of LWJGL later on. I wrote a custom TGA loader and used it to recode one of the basic demos, avoiding the AWT-based loader. I uploaded it all to the devs and said, “Here’s your problem, here’s your fix, and here’s one of your examples recoded to work on the Mac”. And here, months later, nothing’s been changed and even the recoded example wasn’t updated to work.

[quote]I don’t know what you’re refering to about the "“Why in the world would you EVER need that in a GAME?” but usually if many people are questioning your design they have a valid point.
[/quote]
Well, the first thing I need is for model loaders to notify me whenever they require a texture, because I have to download or generate the texture in realtime with a delayed provider mechanism. The first retort is, why wouldn’t you ever not have a texture immediately available for loading? That’s no good when you have a constant streaming content system being provided from a remote server. I made suggestions like model and texture loaders being able to load from streams, but it was why would a game ever be loading resources from anywhere other than from disk? I asked about per-poly texturing, because our Mars game uses real Mars MOLA data where each polygon is almost half a mile in size, but was shot down that my needs were too specialized.

[quote]but usually if many people are questioning your design they have a valid point
[/quote]
Or maybe they’re just not doing what we’re trying to do. Is it a valid point to say that it’s utterly unimaginable that your textures wouldn’t be immediately available, on disk, at the time of model loading? Or that it’s a bad design if that’s the case?

Point being that unless you’re making a Quake with Xith, or making a CAVE with Java3D, you’re basically screwed for Java in terms of what’s available.

For the record, I think these guys do a hell of a job, because I know they’re doing it for free, and I can’t really ask for much. It just annoys me when people harp Java as the best thing since sliced bread and it’s critically missing various options as such, and particularly when I make meager suggestions and then am told that I must being doing something wrong if I could ever think I would have a need like that… like who in the world would ever need something like that? Well, I do… just because people don’t see why you’d ever need it in a Quake game, suddenly means that I must be doing it horribly wrong somehow…

#30

3D Java is being taken quite seriously in the non-gaming market. The thing is that the non-gamers don’t go about attempting to grab ever press headline that they can. Almost all of it is being done quietly away in various laboratories, private studios, research centers etc. One of our partner companies is quietly selling millions of dollars worth of training applications that are built on top of Java and the 3D APIs. However, you’ll never see them in a trade magazine or the front page of the NYT after their latest version launch.

Pssssttt… Jeramie… Take a look at the second line in my sig. If you want to do non-gaming stuff, there’s the answer for you. Try the Beta2 stuff now, and have a look at Beta 3 when we release it early next week. Easily twice the framerates of J3D on identical content, proper multithreaded rendering etc.

#31

Of course the really wonderful thing about these open source projects is that if you don’t like something or want something added that no one else seems to think is worth while you can always add it yourself and maintain a slight branch of source.

Delayed texture loading would seem to be out of the general focus of the folks maintaining Xith or JME. So why not just add it yourself? If you do it really nicely and don’t impact the general use case then you’ll probably find they’ll happily add your changes to the core.

Isn’t that what Open Source was always meant to be about? Feature development based on need, not waiting for someone else to come along and do it?

Kev

#32

I’ve got delayed texture loading and notification in SPGL :stuck_out_tongue: (notice how Super Elvis’ loading screen works)

The thing is it’s an extremely unusual requirement in soft realtime graphics. If you need to display a model with a texture on it next frame, you can’t really be showing a wireframe while the texture loads. You have to have it loaded and ready way in advance or you drop frames. You can either do it at a point when you’re not having to display in realtime, or you can load bits on demand and hope you can get them inside a frame. That’s just the way it is for soft realtime though, of which games is a subset.

Cas :slight_smile:

#33

Actually we just have a pre-loaded model as a placeholder for delayed models in transit, and we just use a flat grey texture for delayed textures in transit. No framerate impact… generally speaking, the placeholder content has a better framerate than the actual content. The entire delayed process works in less than a second or so, and we find that people accept the streaming nature of the system very readily… much more readily than waiting for a 2GB pre-game download to finish, for instance. They’d rather be up and playing, and then only download content as they first encounter it, than needing to install 2GB (ie, EverQuest) all at once for content they may never encounter in their playing experience. I tell ya, dialup people really really appreciate that. Not to mention that we can dynamically modify the universe on serverside and not incur a per-player patch penalty on the next login.

The only reason I asked the Xith devs first is because they already know the Xith source… and when it’s the difference between one person doing it in 5 minutes, versus me taking 5 days just to understand the Xith code enough not to screw it up, I figure I could at least ask first.

As far as Aviatrix3D, it’s not as advanced as our own in-house 3D engine, and like was said earlier, doesn’t seem to have the ongoing development speed of Xith. I guess just any issue not directly related to making Quake games I’ll just have to shut up about.

#34

Hi,

[quote]Delayed texture loading would seem to be out of the general focus of the folks maintaining Xith or JME.
[/quote]
Depends on how you see this. Now I am actively working on reducing memory requirements of Xith3D and want to release texture data after it defined as OpenGL texture (say, lazy texture). I think the same mechanism can be useful for delayed texture loading as well… but it cal also be implemented without any modification of Xith3D engine…

Yuri