Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - nouknouk

Pages: [1]
Support / Re: Applet & memory concerns
« on: October 23, 2008, 11:02:55 am »
about bugs: I would like to hear which bugs that were, that you've discovered (except for that memory hog in the loader)...!?
If you're takling about my post before, i was talking about my experience in the pulpcore framework, not jpct.
So don't worry, I ddn't found any bug in JPCT for the moment ;)

Thanks for your license details, anyway.

Support / Re: Applet & memory concerns
« on: October 22, 2008, 09:41:17 am »
Still, it's up to the author and you have to respect their wishes.
For sure, i never said anything else.

Anyone, I think, can fork code if it's open source, so that might enter in.
Yes anybody can. But in real life, real cases of fork in open source projects are the exception ; it never happens for small or medium sized projects.

Two main reasons:

- as the framework is open source, there is no more temptation to take the ownership of the code. And even if there was, it is totally impossible to make a fork and claim seriously that you are the creator : it's too easy to point similarities between two projects having the same basis (even if it's compiled and/or obfuscated).

- Even if a fork happens, it probably won't survive for a long time : making support of such a project involves a great amount of time for his author. And there are too few people ready to spent their time to support such fork.

Support / Re: Applet & memory concerns
« on: October 22, 2008, 12:35:06 am »

Distributing source code means neither loosing its ownership nor the possibility to keep the control of its evolution.
It has several advantages:
- on 'user' side: being able to better understand how things are done by looking at the code and being able to 'tune' little parts for their own speific use.
- on 'creator' side, to enhance the support by letting users suggest fixes for bugs and/or improvements instead of simple bug reports or ideas. That doesn't means the owner is forced to accept/include them. But it means less work for the 'creator' of the framework.

A good example is a framework I currently use for 'eye candy' 2D applets: pulpCore (under LGPL license).

The official repository is maintained only by its creator (David Brackeen). In other words, David is the only one that has got a write acces to SVN.
But users are highly encouraged to propose new features and/or bug fixes.

On my side, having the source code made:
- I have been able to suggest full fixes for some bugs I noticed.
- I have been able to 'tune' the original framework for the development of kind of personal isometric engine

To avoid any troll: I'm not piece of "open source fanatic" and there's no value judgment on my side.
Just another point of view, nothing more.

Support / Re: Applet & memory concerns
« on: October 21, 2008, 04:32:21 pm »
That question has been asked before and the answer was "Becausse I want it on that way".  8)
Well, you reassure myself.
I would have been ashamed if I asked a question for which someone already answered in the forum ;D

Support / Re: Applet & memory concerns
« on: October 21, 2008, 02:36:46 pm »
ok, thanks for all those explanations.

I would have just another 'off topic' question: why is jpct released as free for 'all usages' (commercial or not) but source code isn't published ? (at all, not a judgment here, I just would like to better understand your approach).

Support / Re: Applet & memory concerns
« on: October 21, 2008, 10:51:21 am »
I think that this is a flaw in the 3ds-loader.

I did a simple test: loading 1000 times the same 3DS file:
                for (int i=0; i<1000; ++i) {
                    Object3D[] objects = Loader.load3DS("pesanthouse.3ds", 0.03f);
                    objects = null;
                    System.gc(); System.gc(); System.gc(); System.gc();
                    System.out.println("["+i+"] mem usage:"+((Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())/1024/1024)+"MB." );

But even after 1000 iterations, the memory consumed remains to 0MB.
So I think it's more closely related to the content of the Object3D class.

I did some other benchs by watching the memory consumption when instanciating lot's of objects with a various amount of triangles:
Code: [Select]
// the getPlane 'quad' parameter is the value I change
// note calling and world.addObject(...)
// has no effect on memory consumption.

                Object3D[] objs = new Object3D[1000];
                for (int i=0; i<1000; ++i) {
                    objs[i] = Primitives.getPlane(10, 1.f);
                    System.gc(); System.gc(); System.gc(); System.gc();
                    System.out.println("["+i+"] mem usage:"+((Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())/1024/1024)+"MB." );

Here are the results:

Code: [Select]
getPlane(2, 1.f); => 8 triangles / object
=> 126 objects / MB
=> 1008 triangles / MB

getPlane(6, 1.f); => 72 triangles / object
=> 66 objects  / MB
=> 2376 triangles / MB

getPlane(8, 1.f); => 128 triangles / object
=> 18 objects  / MB
=> 2304 tirangles / MB

getPlane(10, 1.f); => 200 triangles / object
=> 13 objects  / MB
=> 2600 triangles / MB

getPlane(30, 1.f); => 1800 triangles / object
=> 1.5 objects / MB
=> 2700 triangles / MB

getPlane(60, 1.f); => 7200 triangles / object
=> 55 MB for 21 objects
=> 0.382 object / MB
=> 2750 triangles / MB

getPlane(120, 1.f); => 28800 triangles / object
=> 44 MB for 4 objects
=> 0.0909 object / MB
=> 2617 triangles / MB

Let's dicuss about the results:

- the average memory consumption is around 2700 triangles per megabyte comsumed (I don't rely on results when quad<8, which is not representative, as the memory consumed by the class itself has a big impact). This leads to a memory consumption of 388 bytes for each triangle (to give an idea it's the amount of place taken by 97 float values, or 32 vectors).

note: the results are in line with the memory consumption of my 3DS file (after merging) : 37MB for almost 100k triangles.

=> This looks really high.

In Object3D API, it seems that all information needed by a trinagle is:
Code: [Select]
public int addTriangle(SimpleVector vert1, float u,float v,
                       SimpleVector vert2,float u2,float v2,
                       SimpleVector vert3,float u3,float v3,
                       int textureID, int sec)
Which is something like 17 * 4 bytes = 68 bytes of 'relevant' data (to be compared with the 388 bytes found above).

Thus i suppose this data may be stored internally inside one or several object instances (<= I mean 'java object' here, like SimpleVector(s) or any internal 'Triangle' class).

Maybe that's the main cause of the overhead.

Another point: i discovered the ID of the sector is stored for each triangle. Wouldn't it be more efficient to only store the sector's ID for a whole object instead ?

Support / Re: Applet & memory concerns
« on: October 20, 2008, 10:01:26 pm »
Your tip works well, as you mentionned.

I'm still a bit surprised that for exactly the same amount of 'relevant' data, there is a difference of memory consumption as high as 30MB, just beacuse the data is spread into 300 objects instead of 100.

Anyway, many many thanks for your support, and your concern  :)

Support / Re: Applet & memory concerns
« on: October 20, 2008, 08:10:01 pm »
Thanks for those details, but:

- I already applied optimizations (Config.saveMemory=true ; yourObj.getMesh().compress() ), but the memory error reamains the same.
- the 3ds file is a house composed of only 3 parts (3 sub-objects).
- it's difficult to merge parts as sub-objects are using different textures (roof.jpg and house_texture.jpg). The big texture is a 1024x1024 one, and is about 1MB in JPEG format.
- even when i load the mesh without applying and loading any texture, i still face the memory error.

You'll find all resources (3ds file, java code & textures) here

I added a memory log in the loop code:
Code: [Select]
System.out.println("memory used: "+((Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory())/1024/1024)+"MB.");

At first iteration, i get 16MB of memory used. In a few iterations, it reaches 64MB and throws the exception. Any object loaded seem to use over 1MB of memory...

I'm quite surprised a simple application with - say - fifty objects of 1000 polygons takes more than 64MB in memory.
Isn't it a pitfall in my code ?

Indeed, when I see screenshots of other jpct apps (Robombs, technopolies, ...), i suppose there are lot more objects loaded in memory, and much more polygons in the world....

Support / Applet & memory concerns
« on: October 20, 2008, 02:45:55 pm »

I'm just a new user of JPCT: i'm currently evaluating the possibility to use JPCT to make 3D applet games.

For the moment, i just did a really basic try: instanciating something like 50 objects from a 3ds file:
Code: [Select]
                Object3D[] objects = Loader.load3DS("pesanthouse.3ds", 0.03f);
                for (int i=0; i<7; ++i) {
                    for (int j=0; j<7; ++j) {
                        Object3D pivot = Object3D.createDummyObj();
                        for (Object3D o2 : objects) {
                            Object3D o = o2.cloneObject();
                        pivot.translate(i*8.f, j*8.f, 0.f);

The 3ds object looks reasonable in size, with somehting like 1000 polygons and the texture is about 1MB:
Loading file pesanthouse.3ds
File pesanthouse.3ds loaded...51691 bytes
Processing new material 01 - Default!
Texture named ROOF.JPG added to TextureManager!
Processing new material 02 - Default [Bo!
Processing object from 3DS-file: Box01
Object 'Box01_jPCT2500' created using 124 polygons and 64 vertices.
Processing object from 3DS-file: Box02
Object 'Box02_jPCT2501' created using 124 polygons and 64 vertices.
Processing object from 3DS-file: Box04
Object 'Box04_jPCT2502' created using 762 polygons and 532 vertices.

I'm afraid when i launch this code (as an application, even not yet as an applet), because I get an OutOfMemoryError.

As I know applets are even more constraining than application (64MB of max memory if I remember well)
That's why, I have more and more doubts about the possibility to use JPCT in my applet.

My goal is to make some kind of '3D top view' (something like that). Thus, 50 objects like my house will be something quickly reachable.

Here's my question: do you see any problem inside my code, or any reason that makes my code use more memory than needed ?

Many thanks in advance.

Pages: [1]