I pmed you earlier today.

Quote from: raft on March 15, 2016, 01:59:06 AM

Quote from: Marchioly on March 15, 2016, 12:10:26 AM
Edit: Another problem with the bones format/java serialization is that it removes the ability to obfuscate your code/bones lib (assuming you want to).

it's interesting that you call that a problem but not a restriction.

anyway, it's not a real restriction, you can exclude Bones' classes from obfuscation so serialized format wont cause a problem.

I used the wrong word. A more fitting word would be limitation or shortcoming. Yes, you can remove the classes from obfuscation, but that will just make the process of reverse engineering/deobfuscation that much easier.

Quote from: AGP on March 15, 2016, 06:46:12 AM
The MaxScript part I can handle. Isn't the point of serialization performance? What if we bypass the bones format altogether and create a JSON-serialized format of our own (and we could--and, indeed, SHOULD--add support for importing other formats, such as the IQM)? We could export to a custom format we could call, say, bonesx (that way we could make our own exporters for Max and Blender spit out the serialized and final file). Regarding JSON, I quote the following article: "The results show that Java serialization is slow for a small number of objects, but good for a large number of objects. Conversely, XML and JSON can outperform Java serialization for a small number of objects, but Java serialization is faster for a large number of objects."

http://java-persistence-performance.blogspot.com.br/2013/08/optimizing-java-serialization-java-vs.html

I like the idea of json or at least a text based format. Mainly because it makes it easy to check for errors/debug the problems that library users are experiencing.

On the topic of the speed issue, I have not done any benchmarks since around jdk1.6/java6.

I was of the understanding that java serialization/ObjectOutputStream was slower than a binary format. I have only previously compared it with xstream/kryo/gson. I thought that in general gson's serialization was pretty fast. However, it is worth noting that my previous tests were storing integer/string data rather than complex objects.

Quote from: AGP on March 14, 2016, 04:00:40 AM
Oh, I know. I'm getting as far as a MaxScript that exports skin and bone data. I'm currently creating an intermediate JSON-serialized format. But I do hope to do the Java Serialization from inside 3ds max.

Should we coordinate our efforts?

I would be open to collaborating on it. I am not familiar with maxscript though.

The avenue I took was adding support for the IQM/IQE animation format to some code that was derived from bones.
Format information: http://sauerbraten.org/iqm/

The reason I chose to work with IQM/IQE was because it is a really common format with a lot of importers/exporter script for 3dsmax/maya/blender.

Additionally, the assets from the mmorpg Ryzom, were released with a CC-by-NA license. As a result, I wanted to get those working/take advantage of that.

Link: https://bitbucket.org/ccxvii/ryzom-assets/overview


Edit: Another problem with the bones format/java serialization is that it removes the ability to obfuscate your code/bones lib (assuming you want to).

Edit:Edit: It is worth noting that I have NOT finished implementing the IQE/IQM format in its entirety. I just have the IQE portion done and only the loading of bone information/skeletal animation.

The reason is because my sights are currently set on retargeting the animations from ryzom to my current model skeleton/scale.

Quote from: AGP on February 09, 2016, 02:43:30 AM
Done. I've also posted a job on Freelance.com for anyone who wants to attempt a MaxScript that takes any biped or bones model from Max and directly exports a .bones file. We'll see how that goes, but that would go a very long way towards making Bones more useful.

The problem with that is that the bones format uses 'ObjectInputStream' from the java.io package. You would need to reimplement the whole object serialization protocol (http://docs.oracle.com/javase/6/docs/platform/serialization/spec/protocol.html)

I havn't really looked too hard into bones, but I forked the code last night and am implementing an actual protocol rather than the object serialization (not too bad so far, the relevant code is commented out in places).

I agree that the conversion process to bones is annoying.

Quote from: EgonOlsen on March 04, 2016, 06:01:04 PM
That's not a problem unless you use more than 3 (plus one splatting texture) on each tile. Or you could try to combine the textures into fewer but larger ones.

Alright. Each tile/ square can only have 1 texture type (ex ground/floor/water) currently, but there are multiple textures per texture type. This give me the ability to have more varied terrain.

Ill think about posting the src when I am done. I have not really seen anything similar released for jpct yet.

Quote from: EgonOlsen on March 04, 2016, 05:49:14 PM
You could use texture splatting for that, but it requires that you actually build a custom splatting texture based on your terrain data and you have to use shaders for this. Here's a basic example: http://www.jpct.net/wiki/index.php?title=Texture_splatting_on_a_terrain

Ill give that a try. I was kind of relunctant because i have ~13 textures per tileset/ environment.

I am loading a heightmap, and texturing it based upon the data stored in the map format. I would like to apply texture blending to this.



I use the following for preparing the triangles/UV coordinates


/**
* The terrain heights are calculated now. Now we have to build an
* Object3D from them.
*/
Object3D ground = new Object3D(width * height * 2);

for (int x = 0; x < width - 1; x++) {
for (int z = 0; z < height - 1; z++) {

int x1 = x * 10;
int x2 = (x + 1) * 10;

int z1 = z * 10;
int z2 = (z + 1) * 10;

float southwestY = heights[x][z];
float southeastY = heights[x + 1][z];

float northwestY = heights[x][z + 1];
float northeastY = heights[x + 1][z + 1];

/*
* Triangles start being drawn at the smallest 'x' Cartesian coordinate in jpct.
* You then go clockwise to fill in the rest of the points.
*
*0,1-1,1     
* |  /|
* | / |
* |/  |
*0,0-1,0
*
* Above is a cheat sheet for the coordinates.
*
*
* TODO: Implement it such  we can select the triangle hypotenuse  for the tile based
* on surrounding textures. This should improve blending when that finally gets implemented.
*/


// 0,1
// |\
// | \
// |  \
// |___\
// 0,0, 1,0
ground.addTriangle(
new SimpleVector(x1, southwestY, z1), 0,0,
new SimpleVector(x2, southeastY, z1),0,1,
new SimpleVector(x1, northwestY, z2), 1,0,
fetchTexture(surfaces[x][z]));

//
//0,1____1,1
//   \  |
//    \ |
//     \|
//     1,0,
ground.addTriangle(
new SimpleVector(x1, northwestY, z2), 1, 0,
new SimpleVector(x2, southeastY, z1), 0, 1,
new SimpleVector(x2, northeastY, z2),1, 1,
fetchTexture(surfaces[x][z]));


// TODO
// ____

//     /|
//    / |
//   /  |
// /__ |
}
}


Does anyone have any tips or advice they could give me for making this look nicer?

Thank you for these. I will take a look later. You never know when you will find something useful.