First for UJ's 3 questions,

1 - The reason that simply porting JoGL to SWT is not
enough to run Xith3D, is because Xith3D is dependent
on AWT components and AWT events.  All of that crap
had to be abstracted out to get Xith3D to work with
SWT obviously since SWT DOES NOT use AWT events
or components.  These are the changes that will guarantee
that most, if not all, existing Xith3D apps will not work
with my version of Xith3D.

2 - Sort of addressed this question above, but to be
explicit, yes these changes did need to be made in
multiple packages.  I'm thinking about some further
refactoring of my own Xith3D version to divide even more
things out a little better and make it easier to work
in the code base.  I think that there could be a very small,
core set of stuff that is Xth3D.  The rest would be
add on projects.   The 'userinterface' package represents
a good example of something that should probably be
an add-on package.

3 - Never actually considered the Eclipse people, but that's
a good idea.  I have had my head down in the
implementation of segmentation algorithms, so I have not
been keeping up with where Eclipse is, or what they may
need.  As only the JoGL, and the Xith3D projects help me
in implementing segmentation using level sets.  That
said, if you know how to get in touch with those people,
perhaps the Eclipse project would be a good place to
host this set of tools.  As opposed to some medical
imaging geek's blog, that may or may not be updated
once a year.

You seem to know a lot about Eclipse/SWT.  We should
talk, how do you send personal messages with this
website ?  Is it possible ?

                                       -TOBY

OK,

I just happened to peek in here today, and saw this exchange.
So I wanted to let everyone know exactly what it is that I have
done.

What I have done is really two things.  Firstly, I ported the
JoGL bindings to SWT.  So that you can use JoGL in an ALL SWT
application.  This first part has absolutely nothing to do with
Xith3D.  Secondly, I modified the Xith3D release to use the
JoGL over SWT binding.  This second part obviously required
me to make MAJOR changes to the Xith3D code base.  The version
of Xith3D that I am using runs on both AWT/Swing AND SWT ! ! !

So when I say that the userinterface package was ported to SWT,
what I meant was that the userinterface package can now run
using my version of Xith3D, running over my version of JoGL,
running over SWT.  I hope everyone followed that.  It means
that you can bring up a SWT window, or 'Shell', and put a
canvas in it that has a Xith3D based scene painted in it.
Now, the Swing components that the userinterface package puts
up as an overlay on the screen can now be used as a chat
window, or what have you, with full transparency support under
SWT.

The problem, as I saw it at the time I originally started this
topic, was how to go about merging the changes back into Xith3D.
To do so would mean that almost everyone else's applications
and demos would break, but I would get help supporting a fast SWT
3D rendering engine for free.  Since my business is medical
imaging, and NOT 3D library development, to get the free help
from the open sourcers was very attractive to me.  However, I
quickly realized that there would be an argument over the fact
that my version of Xith3D would break what's been built to date.
Now instead of making everyone else rework applications
that they've spent countless hours on, I decided to just use
the changes myself and not get into flame wars.

That said, I am thinking about starting a blog on the topic of
my version of Xith3D for others who are interested in using
Xith3D over SWT.  I know there are problems with forking just
like there are problems with merging, but I think this is
necessary for several reasons. Primarily, I am lazy, and a
freeloader, by nature.  So if someone else is
willing to do coding, I am more than willing
to benefit from . . . er . . . I mean . . . beta test . . .
their changes to my version.  Another reason that such a blog
may be valuable, is that the version of Xith3D that I have
makes some major improvements to Xith3D including support for
LUMINANCE, INTENSITY and other grayscale-like pixel formats,
as well as, 3D textures.  These things are EXTREMELY useful in
medical imaging.  Not to mention implementing the userinterface
package correctly, so that mouse hotspots line up with the
picture of the Swing component on the screen.  Other
improvments include the ability of JoGL over SWT to support
adding and removing multiple canvases to and from a SWT
window, and supporting java based OpenGL applications with
small memory footprints.  Memory is something AWT/Swing just
does NOT do well.

Well,
There you have it citizens . . .
And now I welcome your questions if anything is still unclear.


                          -TOBY

J,

I am in the process of commenting my repackaged
implementation and putting a zip of it on a publicly
available web site.  When I get done, I will post a message
to this list.

                                             -TOBY

Can anyone explain why the new viewTrans
member has been added if it is not being used?

Is it being used someplace that I can't see?

If you look at the renderStart() method, towards the
end, you can see that we never actually set the
viewTrans member into the PROJECTION matrix mode, NOR
the MODELVIEW matrix mode.

What's the deal here ? ? ?

                                                    -TOBY

AAAAARRRRRGGGHHHH!!!!

You guys changed all the code . . .

Now I know there is a God . . .

No one else would find this shit funny . . .


I'll be in merge purgatory if anyone needs me . . .

                                       -TOBY

That was a BITCH ! ! !

Anyone out there even using the userinterface package,
or did I just waste 3 weeks of my life needlessly ?

UIWindows are a good idea, but I had to change a few
things.  Firstly, transforms were a little off "out of the box"
so mouseclicks could go unnoticed, ESPECIALLY if one were
to resize the window.  Secondly, it was necessary to put
some code in to differentiate when an event was
intended for an overlay, and when it was intended for the
actual canvas.  Also, UIOverlay stuff is useful on its own,
it should not be in the same package as UIWindow stuff.
Of course, that's an academic argument.  Lastly, the whole
thing is glued together with AWT event crap.  All of that
had to be abstracted into interfaces.

Things I wanted to change, but couldn't:

   Views know about UIWindowManagers, Why?
   Shouldn't UIWindowManagers just stick geometry
   into scenes, and views render geometry.  Keeps
   code clean . . . reduces plaque.

Anyway, it's working flawlessly on Swing and SWT now,
even after reshapes of the top level frame.

Yeeaahhh Bwooyyy ! ! !

                                                          -TOBY

OK,

Got it.

Just a little while and I'll submit to IssueZilla.

I made my changes in the code that I found in one of the
downloadable tar.gz packages.  So I have to go back in
make them in the code from cvs.

I'm doing a checkout now.

                                                  -T

Can anyone here give a 30000 foot explanation of the
UIWindow class.  I noticed that there is a heavyweight
frame being held in this class.  Is that necessary ?
Why ?  I assume it's because Swing won't repaint
otherwise, but I'd like to know for certain.

Anyway, a quick 5 minute overview from you guys could
save me 2 or 3 hours of pouring over code.

Holla back y'all . . .

I'll check back tomorrow . . . I'm goin' clubbin' . . .

                                                -T

Uhhh,

Am I missing something here?

How do I get code to Yuri, your e-mail is hidden, no CVS
access . . .

This is going to be a little hard.

Can the community enlighten me.

                                     -T

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

Is there any code or anything released yet ?

I'm in the middle of implementing something very similar for
cross-toolkit SWT.  Can I take a gander at what you're doing
for this?  If so, how, where is the CVS or file store ?

                                           -T

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

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

OK, I'm back and armed with data.

Princec,

An abstraction of GLContext handling will be a little more
tricky than it seems.  Firstly, AWT and Swing both have the
concept of locking and freeing.  These are things you don't
have to worry about in LWJGL Window or with SWT.  That's
why people use those, because they are more simple.
That's also why JoGL on AWT or Swing freaks out if you
try to do any complicated context handling, like removing
and creating Canvases in an AWT or Swing container on
the fly.  This is also the reason for all of the rendering
thread management calls in JoGL, and that's a whole other
mess that AWT and Swing oblige you to deal with.

I think it is instructive here to consider what the people
at JoGL have done to help us in this regard.  They knew
about the assanine nature of AWT and Swing when they
started reworking the GL4Java code, so they hid the
GLContext altogether.  You can't get to it from the public
APIs.  The only HACKish part of the interface to the
GLCanvas is all of the render thread crap and the auto
redraw handling.  However, in as much as there is a
disagreement with those APIs being there, it could almost
be called philosophical.  The fact is you can use JoGL in
a semi-sane manner with what they've given you.

I think this is the model to follow.  Take a close look at it,
and see what you think.


                                                           -T

JCD,

Yes it could, with a few caveats regarding UIWindow
that I'm not sure about yet . . .

I will be soon.

Jens,

Yeah, I agree there are some real cool opportunities
here.  I myself will probably start with an Eclipse shader
program editor, but others can integrate into other
tools, as Xith3D is open source.  As I said, my principle
thrust is to get a shader programming framework that
is useable by MY company, but others are free to do
what pleases them.

Now my REAL question,

Who are Yuri and David ? ? ?

And would they be of help here ? ? ?

Thanx JCD . . .

THAT is EXACTLY what I was hoping for . . .

Right now I am still inventorying the code base.

I just got a look at it in depth for the first time
yesterday.  Tomorrow I will have a better
idea of what I think the abstractions should look
like.  More importantly, I will be able to back up
my assertions with data.  Right now you guys are
WAY ahead of me in your understanding of the
code base.  I have to catch up in order to facilitate
a productive interchange.

I WILL be running some ideas by you tomorrow
though, if you are available.

                                                 -T

Regarding speed, the short answer is that bringing up
a SWT Shell, (equivalent of a JFrame), is SIGNIFICANTLY
faster than bringing up a JFrame in Swing.

The real reason my company uses SWT, is because of a
bug in JoGL on Windows.  If you bring up a Frame or
Window with multiple GLCanvases in it, draw
to them, and then remove all of them and create new
GLCanvases in the same Window or Frame to replace
them, you will get a crash.  Perhaps not the first time,
perhaps not the second, but sooner or later if you
replace GLCanvases enough, a crash will ensue.

This bug was pretty annoying actually.  Haven't tried it
on 1.5, but we shipped our product last year, so we
HAD to go with SWT, or not use OpenGL.  I am revisiting
the situation now to see if there has been any progress.
I think that Xith3D is the only thing out there that we
would have use for, so I am porting it to SWT so that
we can use it in the future, like the next release.

One thing I will say though, our product has really been
kickin' the s#!t out of a competing product also written
in Java, but using AWT and Swing.  Why that is I don't
know, as I have not used this competitor's product, but
there it is.

                                                      -T

I have a question.  I am in the process of porting the
Xith3D engine to SWT, (as well as implementing the
3D texturing correctly , but that's not the subject of
this post).  Half of the work is done.  That is, since I
noticed that Xith3D sits on top of JoGL, I ported the
JoGL binding to SWT.  Now I can use JoGL in a SWT
GLCanvas.  To test that all of the functionality of JoGL
was correctly exposed a volumetric shadow test was
implemented.  This tested everything from shaders to
pbuffers, all at once.  It works fine .  Step 2 is to
implement a Canvas- and Render-  Peer in SWT.  Also
a fairly simple task, however, this is not all that has to
be done.

This brings me to the heart of the post, event handling.
Right now, all of the events throughout the Xith3D code
base are AWT events, that leaves SWT events out in the
cold.  So even though there is a SWT-based GLCanvas
that is acting as the CanvasPeer, there are no events
coming out of it and into the rest of the system.  This
is because the rest of the system is listening for AWT
events, which they will never receive.  My planned course
is to write abstractions for all of the events, and then
listen for those in the code base instead.

I am writing to ask if the actual Xith3D developers think
that this is a reasonable course of action.  There are a
lot of surprises throughout the code base that I have been
coming across.  Like the need to do event handling correctly
in the UIWindow as well as in the general system.  It would
be great to know whether or not there are other gotchas in
the code base, or if you guys planned on implementing
SWT integration in a different way.

Holla Back . . .

                                                          -T