JPatch, FPS???

General discussion about JPatch

JPatch, FPS???

Postby Waniso » Wed May 24, 2006 2:14 pm

Hi guys :D

I'm wondering what's the FPS like for JPatch when rendering an imported mdl object.
Anyone???

:idea: What about loose coupling in future versions of JPatch? Correct me if I'm wrong, but I feel like there are a lot of dependencies in the code...
Waniso
 
Posts: 15
Joined: Thu May 04, 2006 2:09 pm
Location: France

Postby sascha » Wed May 24, 2006 3:40 pm

I'd say on a reasonably fast PC, with OpenGL, for a simple animation with a few simple models the animator could maintain 30fps. But note that it is not optimized for that - its purpose is to render the frames in the GUI at interactive rates, but e.g. all subdivision is performed on the fly for each frame and in software - it neither uses geometry arrays nor display lists, so you can't compare this with something like a game engine.

What about loose coupling in future versions of JPatch? Correct me if I'm wrong, but I feel like there are a lot of dependencies in the code...

I'll gladly discuss design issues with you, but could you be a bit more specific? What exactly is dependend on what...?
There is a strict destinction between entity, control and boundary (user interface) classes, there's a great deal of abstraction and I've sucessfully redesigned some parts of the code without being forced to rewrite the entire application, so I really can't see "a lot of dependencies in the code".
Please don't get me wrong, I don't consider myself an OO-Design guru, so if you've got concrete ideas to improve the design, let me know!
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby Waniso » Wed May 24, 2006 5:42 pm

Of course, we are not comparing JPatch with a game engine ! The reason I am interested with the FPS is that I am currently investigating the possibility to develop a spline engine instead of a poly one for the game I am working on.

With JOGL, the engine is currently running at ~ 80fps.
The game characters are in mdl format (+ their action files), and unfortunately, the export to a poly format (e.g. obj, 3ds) is not working at all ! Time is sort of limited for me as well as resources. So, for a first version a simple MDL loader would work, even it that implies a significant FPS drop!

You may have guessed now my motivations in joining this forum :) Based on my modest knowledge, I think you have developed the first Java loader for A :M ‘s mdl format. Even if there is no bone + action support yet, it represents a great base code for people interested in that.
This leads me to the next point in my previous posting: Loose Coupling.

Perhaps, I might have exaggerated on that but the AnimationMasterImport stuff seems dependent to other JPatch classes (e.g. MainFrame class ), which makes it a lit bit hard for me to isolate the loading code needed without having to go deep in the code. This could be also true if one ought to write a plugin importer for another model without having to take into account all the dependencies. Yet, this is just my point view. No ?

Anyways thanks again for putting these stuff out there for the open-source community !

Kind regards,

Waniso
Waniso
 
Posts: 15
Joined: Thu May 04, 2006 2:09 pm
Location: France

Postby sascha » Wed May 24, 2006 8:44 pm

Perhaps, I might have exaggerated on that but the AnimationMasterImport stuff seems dependent to other JPatch classes

Ok, I see. I have to admit that AnimationMasterImport class belongs to the oldest files and I haven't looked at it for a long time, so it might be one of the worst :?
The occurrance of MainFrame in line 316 is unnecessary and seems to be a remainder of an even older version, you can replace it with
Code: Select all
for (Iterator it = model.getPatchSet().iterator(); it.hasNext(); )  {

Apart this mistake, it should only depend on Model, Patch, ControlPoint, JPatchMaterial and Selection, but these are the classes a Jpatch-model is composed of. And yes, HashCp (which should probably be an inner class of AnimationMasterImport instead).

But sure, the classes are not designed to be used outside JPatch - for your purposes you won't need the full functionality of ControlPoint, and it's possible that these parts of ControlPoint you don't need anyway depend on other classes you won't need too... For example, ControlPoint has some utility methods that depend on MainFrame (JPatch's main class). I agree that it would be better to move these utility methods into another class - for your puproses you can simply remove them. On the other hand JPatch isn't finished yet, and these are issues I plan to fix before releasing version 1.0 - that's also the reason why I won't enable the plugin API before version 1.0.


The game characters are in mdl format (+ their action files), and unfortunately, the export to a poly format (e.g. obj, 3ds) is not working at all !

It should work with JPatch. If it doesn't with version 0.5.x, try it with 0.4. One thing you need to do before exporting to obj format is aligning the patches, check out this page for details.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby sascha » Wed May 24, 2006 9:04 pm

With JOGL, the engine is currently running at ~ 80fps.


There are a few factors that slow down JPatch's JOGL renderer.

1. It uses adaptive subdivision. This means that subdivision is performed for each frame, and it's done in Java. An optimized version could either use a precomuputed polygon version or hardware tesselation (e.g. ATI's n-patches aka truform).

2. JPatch can switch between Java2D, a Java software renderer and JOGL - there is an abstract JPatchDrawable class with implementations for each renderer, but this also prevents some OpenGL specific optimizations.

3. Because of 1 and 2 I can't use vertex arrays or display lists. Each vertex is passed via glVertex() to JOGL, this means that each vertex must go through JNI, which of course has a performance impact.

4. The way the animator sets up transformation matrices is not optimized yet, so for large scenes with complex objects (i.e. lots of bones) this can have a negative performance impact.

5. The way JPatch computes bone-transformation is quite sophisticated, intended for high quality rendering. A realtime renderer would perhaps get by with a much simpler skeleton system.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby Waniso » Thu May 25, 2006 2:01 am

All right, it’s about 3.05 am and I am still JPatching…
Thanks to Sascha’s hints, I sort of isolated all the code related to loading an mdl model.
I am now testing this “isolated module” from the AnimationMasterImport class with a call to importModel(“testModel.mdl”); My traces show the following while parsing the file:

-858 splines
-4236 patches (mapPatches hold all the patches, right Sascha?)
-8 control points for each patch (?) (toString method call for each patch show 8 Cps and the associated material for the patch)

To make this renderable for let’s say a custom Canvas Object I am adding a render method in the Model class. The method signature is: render(GL gl, GLU glu).

Am in the right direction since for each control point I can retrieve its 3D position?
Or is there some other critical info I’m missing?
Waniso
 
Posts: 15
Joined: Thu May 04, 2006 2:09 pm
Location: France

Postby sascha » Thu May 25, 2006 7:31 am

JPatch currently uses Hash's subdivision scheme to render the models.
It is adaptive, but it only works correctly in orthographic viewports - I'll have to adapt it to work with perspective viewports as well.

Rendering non-rectangular (3- and 5-sided) patches is very experimental.

There seems to be a bug with setting up the normals as well, sometimes there are visible shading artifacts (in the relatime renderer only).

To see how JPatch renders a model, start with Viewport2.drawModel()
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby Waniso » Fri May 26, 2006 5:28 pm

I sort of got the model to render with JOGL. But it is not really rendering what I want!!! I get a flat rectangle...I need help with this one!
FPS dropped from 80 to almost 1 :(
Waniso
 
Posts: 15
Joined: Thu May 04, 2006 2:09 pm
Location: France

Postby Torf » Sat May 27, 2006 11:47 am

It's a bit hard to help you with so little information - Could you post what exactly you've done? Perhaps some code snippets or just an explanation which classes/methods you used and how?
Torf
 
Posts: 155
Joined: Mon Nov 08, 2004 8:45 pm
Location: Germany/Konstanz

Postby Guest » Mon May 29, 2006 1:34 pm

well, it goes like this:
....
AnimationMasterImport am = new AnimationMasterImport();
Model model = new Model();
am.importModel(model, "testModel.mdl");
Viewport2 viewport = new Viewport2(myDrawable, myViewDef);
viewport.drawModel(model);
...
Do you have an example that displays an imported mdl in a Canvas?
Please make my day
:)
Guest
 

Postby Waniso » Mon May 29, 2006 2:20 pm

Anonymous wrote:well, it goes like this:
....
AnimationMasterImport am = new AnimationMasterImport();
Model model = new Model();
am.importModel(model, "testModel.mdl");
Viewport2 viewport = new Viewport2(myDrawable, myViewDef);
viewport.drawModel(model);
...
Do you have an example that displays an imported mdl in a Canvas?
Please make my day
:)


Forgot to log in ;)

Waniso
Waniso
 
Posts: 15
Joined: Thu May 04, 2006 2:09 pm
Location: France

Postby sascha » Mon May 29, 2006 3:46 pm

Hi Waniso,

as I didn't think about using some classes outside of JPatch when I wrote them, there are some ugly calls to methods of JPatch's mail class (MainFrame).

As a quick workaround, I've added a
Code: Select all
if (MainFrame.getInstance() != null)
before those calls, but I'll have to clean this up later. So as far as this is concerned you're right - this is in fact tight coupling of classes that don't belong togehter :?

Please check out the latest version (HEAD branch) from the CVS. It contains (among the afore mentioned modifications) a class called jpatch.test.ModelLoader.

It's got the filename to load hardcoded in line 61. It loads a model and displays it (slowly rotating) in a 800x600 OpenGL "JPatchDrawable".

I've added some comments to the code to describe what's going on.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby Waniso » Tue May 30, 2006 1:37 am

Great stuff Sascha :D
I have been playing with the code for hours....All the characters load well, and the framerate is rather satisying with the ModelLoader class. I'll add some metrics to analyze this further.
I'm also currently migrating JPatch to JSR231....Or have you done that already?

-Waniso
Waniso
 
Posts: 15
Joined: Thu May 04, 2006 2:09 pm
Location: France

Postby sascha » Tue May 30, 2006 8:56 am

...and the framerate is rather satisying...

The reason why subdivision is done on the fly each frame is that the renderer was primarily inteded to be used in the modeler. Since the model can change a lot (after all, that's the purpose of a modeler), a pre-tesselated polygon version didn't make much sense.

It would make sense for the animator, as you can only move the vertices, but can't change a model's topology there. I guess the speedup would be significant, but then you'd loose the ability to do adaptive subdivision (which is done right now, but doesn't work correctly in perspective viewports).

Also note that the realtime renderer uses a "cheap" version of the subdivision algorithm. The one used for final rendering takes care to correct surface normals and stich together the hooks. For speed reason, this isn't done in the realtime version.

I'm also currently migrating JPatch to JSR231....Or have you done that already?

I haven't yet, but it's on my todo list. Do you know if the API changed significantly - aside from new package names?
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby Guest » Tue May 30, 2006 1:29 pm

I haven't yet, but it's on my todo list. Do you know if the API changed significantly - aside from new package names?


Migrating to 231 should be fairly simple :wink:

Aside the package name changes, here are some obvious changes needed in JPatchDrawableGL:

-Change GLDrawable to GLAutoDrawable
- Change Dimension dim = glDrawable.getSize() to
Dimension dim = new Dimension(glDrawable.getWidth(),glDrawable.getHeight())
- Insert an additional paramtere 0 to all gl calls e.g. gl.glMaterialfv(side, GL.GL_AMBIENT, new float[] { mp.red * mp.ambient, mp.green * mp.ambient, mp.blue * mp.ambient, GHOST_ALPHA },0 );

-JPatchDrawableGL Constructor: Cannot use createGLJPanel and createGLCanvas , use
glDrawable = GLDrawableFactory.getFactory().getGLDrawable(Object target, new GLCapabilities(),null).
How about the target (e.g. Canvas, JPanel) being passed as a parameter ?
Guest
 

Next

Return to General discussion

Who is online

Users browsing this forum: No registered users and 4 guests

cron