Xith3D for SWT

Engines, Libraries and Tools Xith3D Forums
#21

Yuri,

OK, now I know who you are . . .
I did not mean to offend.

The proposal that you have put forward, I believe will
work. However, I think there it will require more effort
than you’re aware of. Unless I’m missing something,
and I could be, a View requires a Canvas3D, which is
assumed to be an AWT component. Right there you’re
not off to a good start. Throw in event handling and all
that stuff, and you’ve got a pretty big job on your hands.

Now I have to go back and ask my bosses for the time
to make the changes to Xith3D necessary for it to run
over SWT, because it will take more of my private time
than I have. This is bad for two reasons, the first being
that other worthwhile development will stop for a couple
of weeks. The second being that it is an open question
as to whether they would be inclined to donate my
changes back to your project. So I’m in a bit of a bind
right now, as I don’t want to have to support Xith3D
going forward. “Support” meaning to integrate any
changes you guys are making into our system.

At any rate, I am now certain beyond a shadow of a
doubt that any current software written to Xith3D will
not work on the cross-toolkit version. On the upside
the little hacking I’ve done so far works on SWT, AWT,
Swing and with LWJGL Windows. At least, the rotating
cube test I wrote does. This is cool, since it means that
I can implement princec’s dream of a cross toolkit Xith3D.
BTW, princec, you can already mix and match calls to the
different GL instances of LWJGL and JoGL for SWT, just
make certain that you have called ‘makeCurrent’ in the
binding that you are using and either GL’s calls will work.
Will not for JoGL AWT because of the lock and free issues
that I was talking about in an earlier post.

All told I’m VERY impressed that open sourcers made this
engine. You guys should give yourselves a collective pat
on the back, this is TIGHT. A few mistakes were made
integrating too closely with AWT, but I think that came
from following the Java3D spec too closely. There was
probably little thinking about SWT, or the multi-canvas
crashing problems with AWT.

We’re less than a month away though,

THANX GUYS ! ! !

                                      -T
#22

tgeorge,

[quote]View requires a Canvas3D, which is
assumed to be an AWT component.
[/quote]
This assumption, as you mentioned later in your post, is made to make Xith3D scenegraph classes compatible with Java3D. From the other side, the way of using Canvas3D in Xith3D is quite different than in Java3D, so it is easy to factor this inheritance out of Xith3D core. But, as I already mentioned before, Xith3D Rendering Subsystem does not depend on AWT at all (UIWindow depends on Swing, but there are other reasons for that).

If you have some patches that make Xith3D more compatible, it would be interesting to take a look on that.

[quote]The second being that it is an open question
as to whether they would be inclined to donate my
changes back to your project.
[/quote]
Well, this is again matter of your personal opinion about that.

[quote]A few mistakes were made integrating too closely with AWT, but I think that came from following the Java3D spec too closely. There was probably little thinking about SWT, or the multi-canvas crashing problems with AWT.
[/quote]
As of AWT integration, I don’t think that Xith3D is too closely integrated with AWT. Java3D compatibility was a clear design decision, but AWT dependencies can be factored out if this is really necessary. As of crashes and other problems, they are just a bugs and nothing else, and they have to be found and fixed. If we speak about another UI libraries, each of them has its own issues and no one is perfect… …everything is matter of joint efforts we put to make it usable.

Yuri

#23

Yuri,

I guess that’s what I mean, I can make Xith3D not depend
on AWT fairly easily. However, this breaks ANY demo that
has been written to the current API. What I’m wondering
is how people feel about that.
Is the design decision to
maintain Java3D compatibility set in stone and non-
negotiable? If this is something I want open source, should
I start another project or would you guys be willing to put
these changes into Xith3D? Again, all of the demos would
break if you do.

These are questions that have to be thought on. Maybe
I should send you the source and you can decide whether
this is an enhancement to Xith3D, or really another
software package. As you said, its the rendering that’s
important. I tend to agree with that, but people who
have written applications to the current API may not.
Maybe this is just me thinking like a commercial
engineer instead of an open source one, but there are
still ‘customers’ to satisfy here. They just don’t pay
any money. So how is it that they are satisfied? Normally
this is done through backwards compatibility, which is not
easily attained here.

I think we need a lot of people to
chime in on this issue, because I want to get my changes
out as soon as possible, so others can help through
testing or code changes. I don’t think there’s a need for
a long discussion, just tell me whether or not a plurality
of the people would mind changes that break current
applications. I can then fork something if I need to.

What do you guys think?

                                         -T
#24

I thought it was made pretty clear up front that until Xith reaches a major version number things are open to change? (same as most OS projects I suppose).

Kev

#25

Hi,

[quote]However, this breaks ANY demo that
has been written to the current API. What I’m wondering is how people feel about that.
[/quote]
Let’s try to find a way for minimum possible changes in code that uses Xith3D - I believe that this is possible.

[quote]Is the design decision to maintain Java3D compatibility set in stone and non-negotiable?
[/quote]
Xith3D is not 100% Java3D-compatible anyway, and exactly AWT dependencies are first candidates to become incompatible without seriously hurting developers.

[quote]If this is something I want open source, should
I start another project or would you guys be willing to put these changes into Xith3D? Again, all of the demos would break if you do.
[/quote]
Lets check. We anyway can create a branch before we’ll get confirmation from people that use Xith3D that it works. Xith3D already survived several incompatible changes, and [I hope] nobody died.

[quote]Maybe I should send you the source and you can decide whether this is an enhancement to Xith3D, or really another software package.
[/quote]
Would be great, because of I also have thoughts about factoring out AWT dependencies of Xith3D. You can submit patches to IssueZilla.

Yuri

#26

[quote]I thought it was made pretty clear up front that until Xith reaches a major version number things are open to change? (same as most OS projects I suppose).

Kev
[/quote]
It was and I strongly believe this should be the case as we don’t want to be restricted from the start.

Will.

#27

Some good news:

An abstract input library (BSD Licensed) is being created as we speak which could be very useful for Xith3D. I especially like the fact JInput’s in there becasue joystick support would be very nice indeed :slight_smile:

http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=GameDesign;action=display;num=1076380063;start=0

Will.

#28

Thanx,

I could use some help in that department. Currently the
abstraction is only for key and mouse events, and is a
real hack. For example, mousewheel won’t work under
AWT and joysticks don’t work at all. Not that I’ve tested
them.

                                           -T
#29

[quote]well that would help LWJGL support :slight_smile:
[/quote]
The important point is that it wouldn’t actually help it, rather make it irrelevant. To mix Xith3D rendering into your LWJGL context would require both the JoGL and the LWJGL libraries to be present - Xith3D would still be using the JoGL library, it’s just that the output would reach the LWJGL’s context instead.

If Xith3D wants to be independant of JoGL, this doesn’t help - you’d need a whole GL abstraction layer added into the mix. Currently there’s a lot of unnecessarily repeated code between the LWJGL and JoGL bindings, and another abstraction would alleviate this. However, it’s not a trivial task to implement, and if the JoGL context management is split away from the rendering code and the size of just the rendering portion of JoGL isn’t too big, there’s no reason to go through it.

However, Xith3D’s real dependance on AWT comes not in the library itself, but in people’s use of it. Converting a demo written for Xith3D-JoGL to work with Xith3D-LWJGL basically amounts to removing nasty hacks (canvasPeer.getWindow().setLocation(100, 100);) and porting the input code to use LWJGL’s Keyboard instead of AWT keyboard listeners. The mentioned input abstraction may be exactly what you need!

#30 
 However, Xith3D's real dependance on AWT comes not in the library itself, but in people's use of it.  Converting a demo written for Xith3D-JoGL to work with Xith3D-LWJGL basically amounts to removing nasty hacks (canvasPeer.getWindow().setLocation(100, 100);) and porting the input code to use LWJGL's Keyboard instead of AWT keyboard listeners.  The mentioned input abstraction may be exactly what you need!

Iagree with you there - in fact I think it’s high time I write an abstract Window object.

It’s hardly difficult, all you really need is the title, size, location…

Will.

#31

done :slight_smile:

http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=xith3d;action=display;num=1077533097;start=0#0

Will.

#32

(necromancy again, sorry everyone)

So in the current situation, what’s needed to make Xith3D work with SWT ?

Are there any dependencies with AWT or Swing anymore ?

How hard is it to make an Eclipse plugin with a Xith3D panel ?

(I post these questions in case somebody already know the answers. If it’s not the case, I’ll search by myself).