Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (568)
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  
  OpenMali initiative - Trying a bit of tidying about maths libs  (Read 20670 times)
0 Members and 1 Guest are viewing this topic.
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #30 - Posted 2006-06-15 20:23:52 »

Yup a good math library needs to have quality. Even if it isn't as fast as other libraries fine-tuned to a certain engine it must at least provide other benefits that a math library specific to a certain engine doesn't have. It certainly helps discussing the differences and the benefits each math library offers since it's rare for engine developers to document this important info anywhere.

Another subject that would be interesting to discuss for unification would be content loaders for 3d scenes. Each engine usualy has half a douzen of specific content loaders which do exactly the some thing when parsing content. Wouldn't it be easier if we worked together to create a unified library for content loaders? At least the content parsing part would be the same for every engine and the model used to represent the parsed content in memory could be a sort of "dom" model. Leaving only the code to translate from the "dom" representation of the content to each specific engine.

There is a lot more things that can be unified for the benefit of all.
If you are motivated I may dedicate some time : I think it's useful.

BUT do you know the Xith Collada Converter that Croft did ? If you implement COLLADA, you add support for 3DS, OBJ and MD2 by the mean of the COLLADA Converter.. I think it should be made independent from Xith..

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline zingbat

Senior Member




Java games rock!


« Reply #31 - Posted 2006-06-16 10:06:15 »

That may be a good idea. Being xml based it should not be too hard to make it scenegraph independent.
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #32 - Posted 2006-06-16 11:14:24 »

That may be a good idea. Being xml based it should not be too hard to make it scenegraph independent.
I heard some guys saying the XML is way to heavyweight and slow to load... Well we could zip it easily.. For loading speed it's another thing.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline zingbat

Senior Member




Java games rock!


« Reply #33 - Posted 2006-06-16 12:00:12 »

Did they provide any benchmark or demo? Slow compared to what other scene format? Without a benchmark what they say isn't very useful.
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #34 - Posted 2006-06-16 12:18:41 »

Did they provide any benchmark or demo? Slow compared to what other scene format? Without a benchmark what they say isn't very useful.
Ahm right sorry I can't remember wether it was DarkProphet talking about Volatile Engine or a talk about jME... I'll dig into it. What I remember is it was compared to a custom binary file format.

But anyway I think XML is the way to go and as COLLADA is designed to be a standard (and has assets to become so) then I think we should use it if it hasn't really big problems about loading speed.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline zero

Junior Member





« Reply #35 - Posted 2006-06-16 13:01:45 »

That may be a good idea. Being xml based it should not be too hard to make it scenegraph independent.
I heard some guys saying the XML is way to heavyweight and slow to load... Well we could zip it easily.. For loading speed it's another thing.

Of course XML loading is slower than a binary and I don't understand, why geometry data isn't swapped to a binary file, while the diescription about their layout and size (postions, normals, tex-coords,..) and other things is sotred in an xml-based format. Such a hybrid format has both advantages.

However, COLLADA has other other reasons, which prevent a fast loading. The main is definitely that the vertex-elements/attrubites (positions,normals,tex-coords) all may have separate indices. OpenGL (and D3D) do ony support a single index. Now, note that the convertion process is O(n^2), which makes COLLADA unsuitable for fast loading resources at runtime.

For those how are interested, I wrote an article which mentions those points a bit more deep I guess: Creating Three-Dimensional Animated Characters: An Experience Report and Recommendations of Good Practice

Don't get me wrong, COLLADA is a great format, but its main propose is interchangability between digital contant creation tools (3dsmax, maya, xsi, blender,..). It also helps that people don't need to write hundreds of exporters, since COLLADA support is available for most. My recommendation would be: write a abstract collda converter framework.


Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #36 - Posted 2006-06-16 14:03:22 »

That may be a good idea. Being xml based it should not be too hard to make it scenegraph independent.
I heard some guys saying the XML is way to heavyweight and slow to load... Well we could zip it easily.. For loading speed it's another thing.

Of course XML loading is slower than a binary and I don't understand, why geometry data isn't swapped to a binary file, while the diescription about their layout and size (postions, normals, tex-coords,..) and other things is sotred in an xml-based format. Such a hybrid format has both advantages.

However, COLLADA has other other reasons, which prevent a fast loading. The main is definitely that the vertex-elements/attrubites (positions,normals,tex-coords) all may have separate indices. OpenGL (and D3D) do ony support a single index. Now, note that the convertion process is O(n^2), which makes COLLADA unsuitable for fast loading resources at runtime.

For those how are interested, I wrote an article which mentions those points a bit more deep I guess: Creating Three-Dimensional Animated Characters: An Experience Report and Recommendations of Good Practice

Don't get me wrong, COLLADA is a great format, but its main propose is interchangability between digital contant creation tools (3dsmax, maya, xsi, blender,..). It also helps that people don't need to write hundreds of exporters, since COLLADA support is available for most. My recommendation would be: write a abstract collda converter framework.
Please explain further : detail your idea.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline zero

Junior Member





« Reply #37 - Posted 2006-06-16 14:36:49 »

The first part would be a collection of classes which parse a .DAE - collada file and allow to access the data through objects (mesh,..). It would try to use float arrays and nio buffer only for geomeytic data.

One possibe approach would be to use jaxb to autogenerate them. AFAIK, Croft did this?! The problem is that the generated interface is usually pretty ugly:  it uses java.util.Lists instead of arrays and therefore java.lang.Float instead of float, further list contain multiple types which have to be tested with intanceof, etc. I don't have much experience with jaxb, but maybe the generation can be optimized by better configuration files.

From that on, it should be possible to save the data easily into other formats - of course additional helper classes could be usefull. IIRC, there are ongoing efforts for such an approach. I hope such libraries are idependent of math or rendering libs, so they can used widely.. Smiley

Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #38 - Posted 2006-06-16 15:04:11 »

The first part would be a collection of classes which parse a .DAE - collada file and allow to access the data through objects (mesh,..). It would try to use float arrays and nio buffer only for geomeytic data.

One possibe approach would be to use jaxb to autogenerate them. AFAIK, Croft did this?! The problem is that the generated interface is usually pretty ugly:  it uses java.util.Lists instead of arrays and therefore java.lang.Float instead of float, further list contain multiple types which have to be tested with intanceof, etc. I don't have much experience with jaxb, but maybe the generation can be optimized by better configuration files.

From that on, it should be possible to save the data easily into other formats - of course additional helper classes could be usefull. IIRC, there are ongoing efforts for such an approach. I hope such libraries are idependent of math or rendering libs, so they can used widely.. Smiley
Would you commit time to go toward this goal ? You may contribute to Croft code..

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline zero

Junior Member





« Reply #39 - Posted 2006-06-17 02:13:41 »

Well, there is no hurry for myself, as I have written exporters for 3dsmax and Maya for the format I use. However, I think in order to support more DCC-Tools, a COLLADA converter would be the best. So, if Croft would like to, why not..
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #40 - Posted 2006-06-17 13:29:04 »

...for the format I use.
Is it a custom home-made format ?

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline zero

Junior Member





« Reply #41 - Posted 2006-06-17 14:47:39 »

Actually, its a small collection of formats for :

  • (Polygonal-)Meshes
  • Materials
  • Deformers/Modifiers: skinning and morphing
  • Model: hierarchies and references the previous assemblies
  • (KeyFrame-)Animations

These were developed especially to allow realistic characters with skeletal and facial animations, including lip-synchronization, but also for arbitrarily objects. They are used in two projects so far: a Virtual Beergarden and one called 'Visual Attentive Presentation Agents', I posted a link to a video here.

I wrote the exporters since COLLADA could *not* handle Morph-Targets/BlendShapes and Skinning on the same mesh before version 1.4 and even today not all COLLADA 1.4 exporters can handle this. However, COLLADA is getting more popular and better supported and  since v1.4 contains all the needed information, a converter seems to be a good idea.
Offline Jeff

JGO Coder




Got any cats?


« Reply #42 - Posted 2006-06-22 21:52:50 »

Gee. Im disappointed.

I read this as the OpenMall initiative.

I was hoping you guys were going to start a shopping center where I could come, take whatever I want, and if I feel like it make a donation.

Darn.

 Grin

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline zero

Junior Member





« Reply #43 - Posted 2006-06-23 01:21:44 »

Gee. Im disappointed.

Oh that's the last thing in the world I want to - I mean to disappoint you Jeff Wink

It is far from being complete or totally bug-free, but if you or anyone else want to take a look at the current state of my math-lib you can do this via svn:

url: https://svn.monoid.net/public/math/
username: jgo
password: member

This a read-only account, but if you Jeff or anyone else want to contribute, I would be glad to give you a read-write account.


Note: there is a single class (net.monoid.math.algebra.xml.sax.SAXExpressionContextReader), which has a dependency to another package. Since no other class needs it,  just remove it before compilation.

Currently, everything is under the GPL, but I'm open to users. BSD may be a better solution.


A few things using it:

The lib contains some algebra and geometry classes, but I guess the Vector2-3 and Matrix2x2-4x4 ones are probably those of your main interest, so I will limit the description to them for now.


One goal was to separarte the operations and from the data-structures. Therefore all these mentioned Vector and Matrix classes have abstract 'getters' and 'setters' for their elements, whereby the set 'set' operation is optional. Further they use doubles instead of floats.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
public abstract class Vector2 {

    // NO class attributes

    public abstract double getX();   
    public abstract void setX(double x) throws UnsupportedOperationException;
   
    public abstract double getY();   
    public abstract void setY(double y) throws UnsupportedOperationException;

    // Lots of methods follow
}


Similiar to the java.awt.geom.Point2D class every class has a concrete implementations which uses float and double attributes.
This also allows an easy derivation for others referencing to an array or nio-buffer are possible, as well as sparse matrices,..

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
public abstract class Vector2 {

     // stuff from above

    public static Float extends Vector2 {
     public float x;
     public float y;

     public double getX() { return x; }
     public void setX(double x) { this.x = (float) x; }
     .. 
    }

}


Note that speed was not the primary goal using the abstract and therefore virtual getters. Probably, the performance could be increased by overriding all methods (add, multipy,..) in the concrete classes, so that these access the attributes directly instead using the properties and using floats in the special case. However, IMHO a stable implementation comes first and I'm also far too lazy cloning all the methods. (if this would be desired generation of the code would definetly desirable Wink)


Finally, let's come to the operations. Most methods have two overloads like the following example shows:
1  
2  
    public Vector2 add(Vector2 right);
    public <T extends Vector2> T add(Vector2 right, T sum)


The first one creates a new vector for the result of the operation and the second one puts it into the last arguement (and also returns this). Generics allow the usage of the second one's eturn-value without casting:

1  
2  
3  
4  
5  
6  
7  
8  
9  
Vector2.Float a = new Vector2.Float(1.0f, 2.0f);
Vector2.Float b = new Vector2.Float(3.0f, 4.0f);

// returns a new vector, which doesn't need to be a Vector2.Float
Vector2 c = a.add(b);
// put the result in the last arguement and return it. using the genrics,
// the compiler knows that return type is the same that was specified
// as last arguement
Vector2.Float d = a.add(b, new Vector2.Float());


Another goal was that some methods can be used to create mathematical expression, which can be evaluated at any time instead of putting the result into a variable. The usage is as follows:

1  
2  
3  
4  
5  
6  
7  
8  
9  
Vector2.Float a = new Vector2.Float(1.0f, 2.0f);
Vector2.Float b = new Vector2.Float(3.0f, 4.0f);

// the returned Vector's getX method returns  a.getX() + b.getX()
Vector3 c = a.sum(b);
assert( c.getX() == 4.0f );

a.x = 3.0f;
assert( c.getX() == 6.0f );


This is particular usefull for large matrices, since the computation result consumes only two references (== two WORDs) and temporarily plus one times the size of an single element.



Please tell me your opinion and ask if you have any questions.
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #44 - Posted 2006-06-23 13:29:09 »

Gee. Im disappointed.

I read this as the OpenMall initiative.

I was hoping you guys were going to start a shopping center where I could come, take whatever I want, and if I feel like it make a donation.

Darn.

 Grin
Sorry maybe my next dev.java.net project will be that. If Sun wants to be a sponsor, of course  Grin Grin

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
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.

Riven (11 views)
2014-10-02 14:36:20

Pippogeek (41 views)
2014-09-24 16:13:29

Pippogeek (32 views)
2014-09-24 16:12:22

Pippogeek (22 views)
2014-09-24 16:12:06

Grunnt (48 views)
2014-09-23 14:38:19

radar3301 (30 views)
2014-09-21 23:33:17

BurntPizza (65 views)
2014-09-21 02:42:18

BurntPizza (37 views)
2014-09-21 01:30:30

moogie (44 views)
2014-09-21 00:26:15

UprightPath (53 views)
2014-09-20 20:14:06
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

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!