Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (120)
games submitted by our members
Games in WIP (577)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Merge Java3D and Xith3D?  (Read 5216 times)
0 Members and 1 Guest are viewing this topic.
Offline pauldb

Senior Newbie




Java games rock!


« Posted 2004-10-15 07:19:47 »

Hi,
I've started a thread on merging Java3D and Xith3D at:

http://www.javadesktop.org/forums/thread.jspa?threadID=5776&tstart=0

Please contribute your thoughts there.
Thanks,
-Paul
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #1 - Posted 2004-10-15 08:43:45 »

It requires yet another sign up - yet another dumb-ass login and password and email address theft.

Are you sure that's the best place, seeing as Xith's main discussion areas are here and xith.org, and "java-gaming.org" would seem a sensible place for such a discussion even from J3D's perspective?

malloc will be first against the wall when the revolution comes...
Offline pauldb

Senior Newbie




Java games rock!


« Reply #2 - Posted 2004-10-15 08:49:12 »

OK, but that's an example of the two sides not communicating/following eachother's work.

You can probably guess what I'm suggesting from the subject but here is a copy of my post:
----
Hi,
now that Java3D is reborn and has become open source, it occurs to me that the development effort on these two projects could and should be merged.

I understand that there are some significant differences in the implementation. My understanding is that Xith3D is not thread safe because of the goal of achieving faster performance. However, please forgive my naivety, but are these differences insurmountable?

If you apply the same argument that Sun are using for not open sourcing Java itself, that it will lead to splintering, should we not be uniting the two implementations of what is essentially the Java3D API?

There are some big advantages of Xith3D, the performance issue just mentioned, the fact that you can get to the underlying JOGL/OpenGL.

With so few of you guys contributing to the 3D code development, doesn't it make sense to pool your resources and work together on one implementation - that has everything?

Anyway, just a thought for a Friday....
-Paul
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #3 - Posted 2004-10-15 08:49:51 »

(having read the other thread)

This seems a stupid idea, IMHO. Your suggestion appears to be based on little knowledge of the differences between the API's, and zero knowledge of what it would take to "merge" them.

Your question "should we not be uniting the two implementations of what is essentially the Java3D API?" is bizarre. If they are alternative implementations of the same API then aren't they already as "merged" as they need to be: that is the purpose of having an API: it lets you have multiple unique implementations?

What do you feel is wrong with Xith that would be solved or improved? And how do you think that would be achieved by "merging" with j3d? And what form would the merging take? (since they are the "same API" already I find it hard to understand how they could BE any more merged than they already are!)

malloc will be first against the wall when the revolution comes...
Offline pauldb

Senior Newbie




Java games rock!


« Reply #4 - Posted 2004-10-15 09:03:08 »

By the "same API", I'm referring to the fact that Xith3D has intentionally followed the same object model of Java3D.

I acknowledge my naivety when it comes to understanding the detail of the two implementations, however, it still seems to me that there is so much in common that there is room for a single larger project that encompasses the features of each as a set of options or extensions.

I actually like the performance goals of Xith3D but prefer the stability, robustness and (now renewed) support of Java3D.

If it cannot be done or if people don't want it to be done, that's fine, but surely it's legitimate to pose the question without receiving such a torrent of abuse.

Cheers,
-Paul
Offline Herkules

Senior Duke




Friendly fire isn't friendly!


« Reply #5 - Posted 2004-10-15 09:05:43 »

Here is my answer from the Java3D forum:

Quote
Of cource you get my vote for that.

But maybe the differences between the two projects are far bigger than is seems at a first glance when looking the API.

First, Xith3D is not bound to any specification process nor has it guarantee some API stability. So it can (and does) move quickly, always catching up with state-of-the-art 3D technology.

Second, performance and predictability are a direct consequence of being singlethreaded and targeted to a certain way to deliver the pictures (no caves, single CPU, medium scenegraph size, ... or so).

So there are conflicts in the basic goals and requirements that will make such a process hard, if not impossible.

I feel the xith3d guys don't feel any need to do so. They are happy with their stuff. So it would be Sun/Java3D that has to move and try to integrate. Its the Java3D community that wants to have a well-performing 3D API provided as a Sun-supported standard. So it is about ... us?

Same holds for jME me thinks, which also is a highly remarkable effort!

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #6 - Posted 2004-10-15 09:18:43 »

Quote

If it cannot be done or if people don't want it to be done, that's fine, but surely it's legitimate to pose the question without receiving such a torrent of abuse.


I agree my response was not welcoming and happy and wonderful, but it was hardly a torrent of abuse.

To be honest, your suggestion is one I find mildly insulting to Xith, in that it ignores most of the purpose and value of Xith, whilst failing to acknowledge that Xith is doing an excellent job DESPITE the lack of help from Sun (not that I'm attacking Sun here: I'm merely pointing out how well it's doing without being propped up by Sun...).

(much as the jME guys were mildly insulted when I first said they "lacked documentation" Grin)

I'm sorry that I initially mistook your suggestion for something that you'd thought about a lot and knew what you were saying - and judged it on that basis. You still haven't described what  "merging" you intend nor given any reasons for it, and now I realise belatedly that this is because you don't know much about the two techs. I suggest you read up on the very early info about Xith which tries to explain it's purpose, aims, etc - this may help you understand the differences better. You may also want to read the thread on this board that was started when j3d was resurrected; lots was said about various options that xith could take at that point.

malloc will be first against the wall when the revolution comes...
Offline pauldb

Senior Newbie




Java games rock!


« Reply #7 - Posted 2004-10-15 10:26:39 »

I've read the threads and articles that you mention.

It seems to me that the main difference is the threading issue that I mentioned in my original message. Surely issues about licencing can be overcome with willing on Sun's side - which would be needed for my proposal to happen anyway. The other key difference, that I see, is that Xith3D is implemented on top of JOGL allowing direct access to OpenGL which I see as another good thing.

I am not actually criticising Xith3D (so there is no need for you to be so defensive). In fact, quite the opposite - I am all in favour of the development of a 3D scenegraph API in Java that has performance as one of its primary objectives.

OK, let me rephrase my original question:
"Isn't there a strong case for Java3D to adopt the Xith3D goal of making performance a higher priority?
Would it be possible to have a single API with differences in implementation to accommodate different uses (e.g. Herkules mentioned support for CAVES), hidden from the user, with options specified by flags or included as extensions?"

(By the way Blah, Blah, the "I" in API stands for "interface" - the similarity in the object models is why I said the "same API")

Thanks,
-Paul
Offline zparticle

Senior Duke




Thick As A Brick


« Reply #8 - Posted 2004-10-15 12:13:55 »

-1 on this idea. If Java3D needs to be improved then the caretakers of that code should improve it. Xith solves a specific set of problems and should stay focused.

- The above is my opinion and is not intended to offend anyone.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #9 - Posted 2004-10-15 12:28:38 »

Quote
I've read the threads and articles that you mention.


OK.

Quote

It seems to me that the main difference is the threading issue


But what about the most important of all: the use-cases? There is little crossover between the use-cases for the two techs, less if you look only at what their "main" audiences are (Sun has made it abundantly clear that they don't consider games-development a high-priority, both in the design of j3d and in recent statements about where j3d is going; c.f. j3d developers' statements about their belief that j3d and xith should continue - in parallel - unchanged, because they had such different targets)

Quote

The other key difference, that I see, is that Xith3D is implemented on top of JOGL allowing direct access to OpenGL which I see as another good thing.


Yet many of us (sometimes it seems most?) want xith-on-lwjgl too - and many have stated they'd use the latter in preference once it was available.

Here's a great example of the fact that both techs have completely different audiences: it's no problem for xith to run on lwjgl, both are aimed at gaming, and to end up with the extra stuff that lwjgl drags with it apart from the ogl-binding is *fine* for xith, because you *probably* want it anyway.

Whereas j3d doesn't have a justification for running on lwjgl, and sun probably wouldn't be too happy (they would prefer people to be using JOGL - fair enough).

Quote

I am not actually criticising Xith3D (so there is no need for you to be so defensive).


No, but you did appear to be damning with faint praise...Smiley

Quote

In fact, quite the opposite - I am all in favour of the development of a 3D scenegraph API in Java that has performance as one of its primary objectives.


ISTR xith has performance as its ONLY primary objective (aside from method-signature compatability with j3d)?

Quote

OK, let me rephrase my original question:
"Isn't there a strong case for Java3D to adopt the Xith3D goal of making performance a higher priority?


Putting it that way...what does this have to do with xith at all, except as source code that Sun could copy, licensing permitting?

Quote

Would it be possible to have a single API


I'm still struggling to see the reasons why this would be desirable, beyond the implicit "fewer API's with same number of total developers == better tested more featureful API" and the explicit "j3d could be much faster".

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline pauldb

Senior Newbie




Java games rock!


« Reply #10 - Posted 2004-10-15 12:38:33 »

Thanks zparticle,

That is really my point. I do think Java3D needs to be improved. I cross posted here to try and garner some support.

If the performance of Java3D was good enough to support the development of games, would Xith3D have been born?

Now that development on Java3D is starting up again, the reason for my post was to suggest that it draws from the great work being done by you guys with Xith3D and thereby address the primary issue in my mind - performance.

Having said all of that, I do appreciate the point that performance isn't necessary for everyone's application. But surely, optimizations etc. for different purposes can be done under the hood and selected by flags or implemented as extensions.

Let the application developers have one API and switch implementations at runtime.
-Paul

ps no offence taken  Lips Sealed
Offline shawnkendall

Senior Duke





« Reply #11 - Posted 2004-10-15 18:43:12 »

What kind of performance difference are we talking between Xith and J3D?  Can someone drop in some numbers or maybe there was a thread elsewhere on this.

If memory serves me correctly, Xith got started simply because Java3d was effectively dead and several peeps had been developing games/etc on Java3D. They needed a live API and wanted more FEATURE advancement, and since J3D was "in a holding pattern", one possible solution was to make a new independant Java3D.

Correct me if I am wrong?

On topic...
Isn't the biggest gain from unifying Xith dev and J3D dev simply is that there would be a bigger, better pool of developer resources?

[mod spelling]

Shawn Kendall
Cosmic Interactive, LLC
http://www.facebook.com/BermudaDash
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #12 - Posted 2004-10-15 22:58:11 »

Quote
What kind of performance difference are we talking between Xith and J3D?  Can someone drop in some numbers or maybe there was a thread elsewhere on this.


I believe Java Cool Dude did some comparisons with some Java3D demos he ported to Xith3D and the result was that Xith3D was indeed much faster.  There is a thread on it somewhere with a frame rate comparison.  I believe David found that magicosm ran faster too.

In theory, Xith3D should be faster due to the fact it is single threaded.  If in fact it isn't then it probably just needs to be optimised.  My understanding of Java3D is that there is a lot of internal message passing to enable the scenegraph to be modified while it is being drawn.

Quote
 
Yet many of us (sometimes it seems most?) want xith-on-lwjgl too - and many have stated they'd use the latter in preference once it was available.


Xith3D/LWJGL is available.  It isn't as fully supported as the JOGL version currently, but it does work.  The more people that use it the better it will be supported.

Will.

Offline Mithrandir

Senior Duke




Cut from being on the bleeding edge too long


« Reply #13 - Posted 2004-10-16 15:51:27 »

(this thread is everywhere! Going to reply here as the bulk of the responses are here too).

Shawn, the numbers I remember seeing were indicating at least double the framerate.  This feels about right because our AV3D scene graph is getting those sorts of numbers as well.

As for the basic premise of the thread: No, there would be nothing gained at all. Xith3D and Java3D are at the opposite ends of the spectrum. They share the same API, roughly, but the semantics are completely different. Xith3D could not pass the J3D TCK test, and probably never would.  If you were to combine efforts, there would have to be one winner. Either everyone develops Xith3D or everyone develops Java3D, and there's no crossover.  The architectures are like chalk and cheese. It's not even possible to take the code from one and munge it to fit the other.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline pauldb

Senior Newbie




Java games rock!


« Reply #14 - Posted 2004-10-16 18:17:39 »

Hi,
Quote

Either everyone develops Xith3D or everyone develops Java3D


I guess that's really what I was trying to say in my original post but didn't phrase it very well..
("merged" was totally the wrong word to use - or at least I should have said "merged the new development effort")
Both Mithrandir and Shawn expressed it better than I did.

Given the limited number of people available to work on developing both Xith3D and Java3D, wouldn't it be better to put all of the development effort into one project or the other?

Now the problem becomes "which one?"

Java3D was neglected by Sun for a couple of years. I would argue that that neglect and its relatively poor FPS performance for games led to the birth of Xith3D. Of course, Xith3D has other advantages - it  sits on top of JOGL/OpenGL or LWGJL allowing access to those.

Now Java3D has been resurrected. And all those people doing scientific visualization or work in CAVEs etc where multithreading is important will say that they don't need the games level performance of Xith3D. But it also strikes me that many people who do that kind of stuff develop their own APIs anyway (eg Aviatrix3D from the J3D people), or had left Java3D during its demise.

But although Java3D has been resurrected - and even though there is Sun staff working on it - and doing a great job - there aren't many of them and Sun's hope is clearly that it will mostly be developed through the "community".

My point - had I expressed it better - is can the community develop two different though similar 3D scenegraph APIs? (add in a third with JME, a fourth with Aviatrix, any more?)

My own personal preference is that all the effort goes into Xith3D but I'm biased because I develop desktop applications. Even now and even as a big fan of Sun (cf IBM/Microsoft) I also wonder about Sun's long term support of Java3D - I wonder how much of the current support is wrapped up with Project looking Glass.

So, I would say that the community should maintain Java3D for those that need it as it is, but that all new development effort should go into Xith3D.

Xith3D has taken the object model from Java3D because it was extremely well designed. But it's moved things on.  It's now added faster performance. Its provided the flexibility of OpenGL calls. The Java 3D development should all be going into Xith3D and that should be backed by Sun.

I hope this clarifies,
-Paul
Offline kevglass

JGO Kernel


Medals: 188
Projects: 24
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #15 - Posted 2004-10-16 18:53:19 »

Not really Smiley

Are you suggesting some sort of mandate to the community at large as to where they spend their efforts?  

At the end of the day community effort is driven by need, people that need Java 3D to be fixed and/or improved will do so. Likewise Xith3D.

I for one am not really sure what changes you're hoping to achieve?

Kev

Offline pauldb

Senior Newbie




Java games rock!


« Reply #16 - Posted 2004-10-16 19:39:36 »

Hi,
I wouldn't dream of mandating anyone.

I agree with you to a large extent. However, I also feel that many in the 3D java community will stay with Java3D simply because that is the Sun backed project. Whereas, I think Xith3D could still satisfy their requirements.

I think more could be achieved - for everyone - with a single united effort - backed by Sun. Or at the very least a lot of cross-pollination of common aspects.

Anyway, it's just an opinion, a thought, not a mandate.
-Paul
Offline Mithrandir

Senior Duke




Cut from being on the bleeding edge too long


« Reply #17 - Posted 2004-10-16 19:48:10 »

One of the advantages that Java3D has, and why people would stay with it is that it is not open source.  There's a big specification process around it, and for them, stability is more important than features. There isn't different versions of the API every 2 weeks and changes come once every couple of years - which is good enough to fit within their development cycle.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline Yuri Vl. Gushchin

Senior Duke




Speak Java!


« Reply #18 - Posted 2004-10-17 07:29:21 »

Hi,

If nothing changed since Java3D has been "open-sourced", then the licensing is a biggest issue for me. In fact, the Java3D license prevents me from distributing modified version of it with my app, even if it is not interfering with the other apps on the system.

For me licensing is a biggest point even to start any effort in the Subj direction.

Yuri

Yuri Vl. Gushchin
JProof Group
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #19 - Posted 2004-10-17 09:12:51 »

Quote

I guess that's really what I was trying to say in my original post but didn't phrase it very well..


OK, I've got you now.

Quote

Given the limited number of people available to work on developing both Xith3D and Java3D, wouldn't it be better to put all of the development effort into one project or the other?


A question which many asked when Sun resurrected j3d, and the cynical often felt Sun had decided to conveniently ignore for reasons not much more complex than NIH syndrome. I can't speak for j3D users, but I agree with your guess that many of the primary j3d audience appear to have migrated to other things during the years of drought. I would love to know how the landscape looks there (and I'm glad we hav people like Mith around here so we at least get a window onto that perspective - the other scivis people I know (mostly chemists) don't use java at all, so they're no use Smiley)

Quote

But although Java3D has been resurrected - and even though there is Sun staff working on it - and doing a great job - there aren't many of them and Sun's hope is clearly that it will mostly be developed through the "community".


Which, if you ask me, is too little too late (from sun). 5 years ago that might have been a smart idea. Nowadays many people have given up on the train-wreck that j3d became (unsupported, underfunded, unmarketed) - and many have found other alternatives.

If I were deciding which oss API to contribute to now, I'd pick Xith over j3d instantly - I trust that an API which was founded out of frustration and a demand for higher performance has more of a future than one that got cancelled for a long time and then resurrected without much clarity of vision. Shrug. IMHO.

But I'm not in the target audience for j3d Smiley so - fair enough - I'm probably missing the point Wink.

Quote

My point - had I expressed it better - is can the community develop two different though similar 3D scenegraph APIs? (add in a third with JME, a fourth with Aviatrix, any more?)


My guess is that Sun will have a hard time getting people to work on their API. Trust and respect are important aspects of oss development, and even if Sun had veritable saints working on j3d now it's still hard to trust them - because it's not hte people that get to pull the plug in 12 months time if it doesn't work out, it's those higher up the food chain.

Now, if j3d were being championed by a senior exec, and had a huge marketing drive, things would be different. But as it is it would still be relatively easy for sun to sweep under the carpet in a few years.

<cynical>I did wonder if j3d is part of a new "experimental" strategy from sun: Take all those things we had that were popular (but we didn't really listen) and which we massively under-supported and under-sold (too little marketing effort etc), bring them back to life, and give them a couple of years to bear fruit. If not, kill 'em again.

The biggest example would be Solaris (on intel) - my free CDs of which Sun still hasn't sent me from several years ago (lookup the news stories about cancelling solaris on intel and what happened next)
</cynical>

Quote

So, I would say that the community should maintain Java3D for those that need it as it is, but that all new development effort should go into Xith3D.


You sound like you're evangelising xith, which imho makes more sense than your original thrust. Basically, for "normal" (non scivis) users I find it hard to understand how j3d is anything but a vastly inferior option to xith (performance, support, stability, trust, etc - e.g. the current build of j3d keeps crashing my OS!).

I couldn't see in the first place what possible benefit xith would have with any closer alliance with j3d, beyond marketing. If sun would market xith side-by-side with j3d, that would be a massive boost - but then I believe people would flock to xith, and sun seem to have difficulty accepting that kind of scenario.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #20 - Posted 2004-10-17 09:22:50 »

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 Grin.

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 Wink.

malloc will be first against the wall when the revolution comes...
Offline DonCrudelis

Junior Duke





« Reply #21 - Posted 2004-10-17 10:32:08 »

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
Offline Mithrandir

Senior Duke




Cut from being on the bleeding edge too long


« Reply #22 - Posted 2004-10-17 12:34:54 »

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.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline JeramieHicks

Senior Newbie




Java games rock!


« Reply #23 - Posted 2004-10-19 17:53:54 »

Quote
And jME just needs more press


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


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.
Offline princec

JGO Kernel


Medals: 407
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #24 - Posted 2004-10-19 18:10:42 »

Good Smiley The more these APIs focus on doing what they're meant to do, the better they will be at it Cheesy

Cas Smiley

Offline JeramieHicks

Senior Newbie




Java games rock!


« Reply #25 - Posted 2004-10-19 18:39:34 »

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.
Offline cep21

Junior Duke




Java games rock!


« Reply #26 - Posted 2004-10-19 20:20:54 »

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.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #27 - Posted 2004-10-19 20:25:16 »

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.


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]).

Quote

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.


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 Wink).

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 Smiley)

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

malloc will be first against the wall when the revolution comes...
Offline JeramieHicks

Senior Newbie




Java games rock!


« Reply #28 - Posted 2004-10-19 21:06:39 »

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


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.


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


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...
Offline Mithrandir

Senior Duke




Cut from being on the bleeding edge too long


« Reply #29 - Posted 2004-10-19 21:37: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.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (52 views)
2014-10-17 03:59:02

Norakomi (44 views)
2014-10-16 15:22:06

Norakomi (33 views)
2014-10-16 15:20:20

lcass (38 views)
2014-10-15 16:18:58

TehJavaDev (68 views)
2014-10-14 00:39:48

TehJavaDev (68 views)
2014-10-14 00:35:47

TehJavaDev (60 views)
2014-10-14 00:32:37

BurntPizza (73 views)
2014-10-11 23:24:42

BurntPizza (45 views)
2014-10-11 23:10:45

BurntPizza (86 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!