Why Java3D

Java3D is a good 3D renderer for some programs but I think it can be one uped by JoGL which is Java and OpenGL bindings. The difference between the two is that JoGL is hardware accelerated, has easier installiation into the java environment, and you'll find alot more people that can program OpenGL willing to help than Java3D. thought i would inform.

Ive been programming java since 12-13 and used JoGL for a considerable amount of time so if you (RepRap) become interested, i'll be willing to assist although i do not know how you do the software now.

I also thought i posted this before but must of forgot to press ok because i couldnt find it anywhere.

Edited 2 time(s). Last edit at 01/10/2008 01:32PM by Mythprogrammer.

I've noticed that the graphics, the build simulation in particular, tend to bog down the app. It's better than it was but still a bit sluggish. As far as I can tell, the renderer is spending a lot of cycles sorting the Z-order of all those filament segments. Anything that could be done to speed that up would help a lot.

I think we have more urgent things to work on that speeding
up graphics right now -- like making sure all Darwin parts
are actually printable with the current system (!). "Does
it actually print?" is more critical than "Can it go faster?"
for an initial system release.

However, if someone not on the core team wants to work on
that kind of optimization and submit patches once they have
something working, that could be a helpful contribution.

There is a script I wrote a while back called

setup-reprap-host-dev-environment.sh

that is a quick way to get you set up to do Reprap
host software development on a Linux platform. Or
you can follow the instructions on the Wiki at [reprap.org] [http://reprap.org/bin/view/Main/RepRapDeveloperInstallLinux] .

Also, if you have good expertise with Java 1.5 threading,
concurrency, synchronization, etc. please step forward,
we have something where a real expert on that could be a
huge help at the moment -- that's IMO way more important
right now that how fast the graphics are. PM me for more
details if you are able to help with that.

Jonathan

---

---

Jonathan

Yeah, that kind of bugs me. I mean, sorry for being childish, but I soooooo want to see the segments extruded like one by one by one, and not just random jumping to a completely different layer. I don't have much programming experience outside basic Java (From prog 1 and 2 in highschool), but I do understand stuff. I second the notion that the graphics should be accelerated somehow.

---

Jay

well i have some free time and didnt expect 3 responses in a couple of hours so i'll whip something together to maybe convince someone to work out the details if the program thats used is object oriented in its programming, should be easy to swap out Java3D for JoGL

Edit: I was looking through the j3d-org and looks like they have stl loaders so that shouldnt be a problem.

Edited 1 time(s). Last edit at 01/10/2008 03:50PM by Mythprogrammer.

> Yeah, that kind of bugs me. I mean, sorry for being childish, ...
> ... I second the notion that the graphics should be accelerated somehow.

Ummm. Please, try to understand. We just can't take on this kind of
"I'd really like" stuff at the moment, it's not realistic. If you can
do it and send us diffs (patches) that result in improved and working
code, great! Otherwise, non-essential WIBNI ("wouldn't it be nice if")
type of things probably have to wait until after v1.0 is released.

If you see something that you believe is truly necessary to get us to a
release-able state, speak up. If you see something you want to tackle
yourself, because it matters to you, cool -- say so (so everyone knows
you are working on it) and then go for it! But "I second the motion"
just doesn't work ... we don't have the spare programming time right
now to indulge in things like this. It's not that they are bad, or
anything... we just have to prioritize in order to ever get to a v1.0
release! We're an all volunteer team, working in our (sometimes almost
non-existent!) "spare time" on this project.

Jonathan

---

---

Jonathan

alright then i take on the challenge to go in the direction of JoGL. is the source code for the current project available with documentation (if no documentation, could wing it)


Edit: Must say the code is well commented and the Javadocs will help. You guys have some high end programmers over there, you have my respect

Edited 1 time(s). Last edit at 01/10/2008 03:59PM by Mythprogrammer.

Mythprogrammer wrote:

> alright then i take on the challenge to go in the
> direction of JoGL. is the source code for the
> current project available with documentation (if
> no documentation, could wing it)

> Edit: Must say the code is well commented and
> the Javadocs will help. You guys have some high
> end programmers over there, you have my respect

Other than the comments and JavaDoc stuff, see
[reprap.org]
[http://reprap.org/bin/view/Main/SoftwareDocumentation]
for some overview docs that could help.

As for "over there"... heh... this team is scattered
over pretty much *everywhere*! Programmers on at
least three continents :-)

Jonathan

---

---

Jonathan

well if usa isnt on the list, u can add it now i'm startign work on the project. I noticed the .classpath and .project files in the zip so im assuming you guys use eclipse too I also wanted to add in a class that'll load the appropriate dll's and jar's for the operating system so no one has to download any file other than reprap's host program.

Mythprogrammer wrote:

> i'm startign work on the project. I noticed the
> .classpath and .project files in the zip so im
> assuming you guys use eclipse too

Some do, some choose not to. Use the tools that
work for you!

> I also wanted
> to add in a class that'll load the appropriate
> dll's and jar's for the operating system so no one
> has to download any file other than reprap's host
> program.

We already have DEB packages and a Windows .exe
installer being developed and tested, I'm not sure
there's value in trying to do that inside our code?
Making it 100% OS-agnostic might be fun too... .DLL
files are useless if you are running Linux or OS X.
Do you have access to all three main host platforms
for testing on?

I'd suggest working on one change at a time :-)

Jonathan

---

---

Jonathan

lol yea, i have virtual machines running on this computer for CentOS/WIN2000/WINXP, macs i have a grudge against

i'll hold off on the dll/jar loaders till i see the installer

so far the work on the code is somewhat tormenting the graphics are intertwined with the stl loading and im seperating them into two different catagories, the model data and the rendering of the model.

Also some side news, if i remember correctly from an article Java3D had support for it stall a while ago because the main guy left. Im nto sure if it was picked up again but at least there'll be an alternative for JoGL.

[rapidshare.com] - 32 bit
[rapidshare.com] - 64 bit

Here are my demos for Win32 bit and Win64 bit. The jars and dlls [should] be a able to be swapped with the Linux counter parts for JoGL (I don't think the j3d jars need to be changed).

This demo was just to display the performance of JoGL over Java3D. I'm still making the changes to the program but honestly its a large amount of code and it may not be entirely possible. :/

However I will still make changes to it until I get a definitive answer to if it can be changed or it can not be changed to JoGL.

(All that should happen is the wineglass stl object will load and rotate on a skewed axis. Adding lighting in next demo so you can see the object easier.)

Edit- Oh, run the program in the console (provided run.bat) so if you get a problem, u can post the error here.

Edited 1 time(s). Last edit at 01/11/2008 12:27AM by Mythprogrammer.

fantastic!

i know jonathan harps on not changing stuff until v1.0, but if you can convert the host software to use a better 3D rendering system, and it all functions identically, then that is AWESOME and I will fully support you and will argue for getting your changes into the main trunk of our code.

Keep up the good work!

lol thanks for the support. when i started doing 3d in java, i ran across java3d as well like this software did and i used it in a spanish project displaying paintings in a art museum [recieved an A naturally ].

But the performance brought problems that gl4java and jogl solved. Focused on Jogl because, as far as I can tell, its true to the opengl programming without programming in c/c++ and its still active so the performance now has a chance to be inproved on sun's side.

And again thanks for the support im free for next few days so look for more notices

well im calling it a night, midnight here. I'll reattempt in the morning. my process so far is getting the concepts down and making the objects I need work in the demo before I start implimenting untested code. Right now my biggest problem is orienting the image on the screen. The wineglass for example starts around 140 in the x coordinates and im trying to get everything relative to a common point so that one point represents origion and is centered on the screen. if i can do that then i can release the next demonstration that'll let you load any stl file and manipulate it in the world (rotate/translate/zoom). I also want to get clipping in place so i can do a psuedo layering process.

Edit: I didnt get that much done this weekend. Im a little rusty with opengl and modeling so I have a few books im getting so i can refer to them and brush up, maybe better news next weekend but i do expect promising results before the end of the month

Edited 1 time(s). Last edit at 01/13/2008 09:33PM by Mythprogrammer.

I saw something over the weekend that makes me think that the "does it actually print" and "can it go faster" problems are becoming the same problem. Vik Olliver posted something on the main blog [blog.reprap.org] that implies that the host software is using so much memory that Java's garbage-collection routines are interfering with the motion of the extruder head.

What Vik ran into looks similar to what I've seen while playing with STL files. Large, complex parts use up a lot of memory and, even after the run (or simulation) is completed, the memory isn't freed up. Doing multiple runs in succession without shutting down the host software in between will eventually give you an out of memory error.

It may have nothing to do with Java3D, though. It sounds suspiciously like "data cancer". If that's the case, it may just be a matter of cleaning up the data model a bit.

Is there someone out there who is really good in java? If there is, they could be a huge help right now, otherwise, I can get my dad to get all of his computer programmers to have a look at it.

---

Jay

I just tried profiling it using TPTP but didn't really learn anything useful other than confirming that it's creating a huge number of objects (mostly Rr2Point). Based on the conversation going on over on the main blog, it sounds like Adrian already knows the source of the problem, so I'm guessing there will be a fix shortly.

This is a fascinating project.
Java wouldn't have been my first choice. I guess if you're going to pick one that everyone has access to it makes sense. I'd have picked lisp, it's a language that's very much in the spirit of RepRap because Lisp has a really good macro system that allows you to write programs that write programs.
Of course, I haven't had a look at the software so I don't know what it does exactly and I'm a little biased because I'm not a fan of Java but I am a fan of functional programming languages. If I had to choose a language for speed though, I'd still not pick Java, I'd pick something like Ocaml, which is very fast, usually as fast as C and due to providing better abstractions, a bit faster on account of the code being in better shape. Lisp isn't exactly slow though, a good lisp implementation will only usually be half the speed of C on a bad day.
But there might be good reasons to pick Java, I just don't know what they are.

This is an open source project. So write an implementation of the host program in Lisp. Or Ocaml. There have been people speaking about writing it in Squeak (for the OLPC). There is also a limited version written in Python. Just make sure it works and keep it updated. Otherwise it'll be gone in no time.

--Blerik

(The reasons for Java are pretty evident: It is good enough. There are faster languages, more flexible, more obscure, prettier, lots of other things. But none have the balance of Java: fast enough, simple enough, flexible enough, big enough user base, runs on enough hardware)

funnily enough, I just suggested a squeak/croquet implementation with the 3d graphics handling being kept seperate from the basic driver software to the people who run croquet (which is also more or less the same people who are behind squeak and OLPC)..

I have posted the email I sent them on the following thread - [forums.reprap.org]

I probably should write a lisp implementation.
Now to find enough time.