aptal karga (foolish crow)

[raft]

yes, i did use octrees. as in fps demo, i simply merge objects to a single one, create the octree from result and then assign it. didnt help much

glVertexArrays makes a slight difference on a ~20000 poly scene

Code Select Expand

r a f t

[raft]

as rolz asked for useful ideas, here is one. i use it since my first viewer prototype and find very convenient

if you use xml for static configurations (ie. not changed during program run) this is a simple receipt to make it robust and light-weight

* use jibx to convert your xml file to a tree of java objects. this eliminates those regular xml parsing issues which are both painful and error-prone
* serialize your object tree to a file
* re-compile the classes that make the object tree (as jibx uses bytecode enhancement, after using it your classes gets fatter and you need jibx runtime in your classpath to use them)
* now you can de-serialize that file in your program and use it without jibx runtime
* dont forget to manually assign a serial version id to your serializable classes -as below- otherwise above will fail

another advantage of this method is, since jibx uses reflection, you can make your configuration classes very small: with no setters-getters and almost all fields final

the result is, you get rid of xml parsing code and have a pure type-safe configuration in very little space

Code Select Expand


public class SomeConfigurationClass implements java.io.Serializable {
   private static final long serialVersionUID = 999;  // 'manually' assign serial version id
   
   public final String aStringValue = null;
   public final SomeOtherConfClass aComplexConfValue = null;
   // no need even for a constructor
   //..
}


Code Select Expand

r a f t
cheers :wink:

[Anonymous]

re-organizing terrain structure, including:

* an xml based terrain configuration as usual
* allowing max instance and reference clones (via max script) to decrease memory usage
* a simple LoD (level of detail) implementation
* switching between nodes is more like games now, simply walk to door
* changed to way balloons pop up

i used a transition area for LoD to minimize pop effect. i.e. only after the transition area is passed the object is replaced with a different mesh

following diagram demonstrates the transition area in LoD system (1, 2 are different LoD levels and the arrows indicates movement direction)

Code Select Expand


---- LoD (1) --->| (1) |---- (2) -->
<--- LoD (1) ----| (2) |<-- (2) ----


below image shows an extreme sample demonstrating LoD running. that is a huge map (1km x 1km in human scale) consists of 100x100 tiles each has 1000 polygons. that maps loads in a couple of minutes on my box and doesnt fit into a 256mb jvm. but runs fast enough



avatar panel is also transparent now. these are addictive on me with no doubt

Code Select Expand

r a f t

[raft]

oops, forgot to login for post :oops:
and it is a 10x10 tile map. i cant correct it as i posted as guest :oops:

[manumoi]

Very nice! And yes... transparent panels are addictive :lol:

[raft]

obviously they are :shock:

one note about transparent panels, maybe it may help another addict :wink:

i found my self doing a common mistake. it is written every where but i did it  :oops: they say 'dont put your rendering code into your paint method, but simply copy a pre-rendered image' swing calls paint of background component everytime the foreground transparent one is repainted. and if you do a render as me in your paint method.. !$%@

Code Select Expand

r a f t

[raft]

since my last post:

* added jump
* some gui impovements and add-ons
* added 'dont see a user' option. (both sides simply dont see each other anymore) this has no take back at the moment so use it carefully ;-)
* added one way (client to server) heart beat mechanism. this is certainly necessary to detect network failures (especially in wireless ones)
* added basic i18n (internationalization) support. translated most parts to turkish but i've noticed that it's really hard to use turkish in computer generated messages :shock: for instance prepositions are in form of suffices which change depending on both wovels and last part of the word :evil:
* changed the way animations are loaded (from pre-serialized data). this takes 25% much space (than 3ds) but loads almost 20 times faster.
* added stand and talk animations (well in fact only the mechanism, animations are dummy). paired animations (like kissing each other) is coming soon. stand by
* prepared a formal business plan. for god's sake, should i ever able to find resources for this project  :roll:

btw, i still think much can be done to decrease the serialized data size (with custom writeObject(..) and readObject(..) methods). even the mesh of a simple cube takes 2.5k space when serialized  :?:

Code Select Expand

r a f t

[rolz]

Looks nice, i'm going to check it out.

regarding heartbeat what transport do you use for the game - HTTP or just plain TCP/IP or UDP ? I assume in case when you use connected sockets you will not need heartbeat at all

regarding serialization - are you sure you need to send mesh data over network ? You may want to choose lightweight objects with minimum required data - like name, gender, body type, hair color and so on - and a factory on client side that will create 3D objects from lightweight ones.

a couple of other tips on serialization - use transient modifier for fields which are not required to be passed over network. you could use ZIP compression to reduce size of serialized objects.

There could also be other techniques that further reduce serialized object's size. Technopolies uses javabeans-based serialization which writes only modified values when serializing the object. It is still flexible and capable of serializing full object graph but has some limitations and drawbacks which may or may not be applicable to your project. If you are interested I could share this code as it is does not have dependencies from the game engine at the moment.

Code Select Expand


WRITE:
Beans: -30ms; Size: 18000
Serialization: -60ms; Size: 421100
Serialization+Zip: -100ms; Size: 122000

READ:
Beans: -280ms
Serialization: -5606ms
Serialization+Zip: -6246ms


[raft]

regarding heartbeat what transport do you use for the game - HTTP or just plain TCP/IP or UDP ? I assume in case when you use connected sockets you will not need heartbeat at all

no udp or http. i use primarily tcp and for some criticial state information rmi (my type safety obsession :roll: ) i'm afraid heartbeat is necessary even for tcp sockets. otherwise you cannot detect -for instance- an unplugged network cable during inactivity.

i was testing karga in a friends' wireless network. they somehow disconnected but the server and even the clients didnt detect it. i dont know much about tcp low levels but i cannot find any other explanation for this

regarding serialization - are you sure you need to send mesh data over network ? You may want to choose lightweight objects with minimum required data - like name, gender, body type, hair color and so on - and a factory on client side that will create 3D objects from lightweight ones.

lol, you got me wrong. i'm not sending mesh data over network for sure. i was talking about about loading animation meshes from serialized (instead of 3ds or md2) files during startup

thanks for the suggestion, it sounds good. i do something similar to your 'incremantal serialization' as i wrote in my first jpct days. i believe, using transient fields in cooperation with readObject and writeObject methods may significantly lower the necessary space for serialized meshes or other jpct objects. helge are you with us ? :wink:

Code Select Expand

r a f t

[rolz]

no udp or http. i use primarily tcp and for some criticial state information rmi (my type safety obsession :roll: ) i'm afraid heartbeat is necessary even for tcp sockets. otherwise you cannot detect -for instance- an unplugged network cable during inactivity.

i was testing karga in a friends' wireless network. they somehow disconnected but the server and even the clients didnt detect it. i dont know much about tcp low levels but i cannot find any other explanation for this

TCP/IP sends ACK packets automatically to track connection losses. I believe that wireless network adapters somehow allow network to operate for some time, waiting for connection to be restored prior to claiming connection loss.

p.s. nice to see you people back after summer hiatus

[raft]

as i know, ack's are only sent in response to other packages, as receipts. if application doesnt send any data, no packages will be transfered. when the socket is closed (either manually or by an application crash) a connection reset or whatever package is sent to notify peer. but i'm not sure, i dont know much about tcp as i said. who cares, as long as java net api's keep this much high level :wink:

p.s. nice to see you people back after summer hiatus

thx

Code Select Expand

r a f t

[EgonOlsen]

i believe, using transient fields in cooperation with readObject and writeObject methods may significantly lower the necessary space for serialized meshes or other jpct objects. helge are you with us ?

What can be made transient in Object3D without much hassle already is transient. I don't see how to improve this further without adding more internal complexity to Object3D. For example, it would be possible to not serialize the vertex normals...but only if you haven't changed them in your code by using an IVertexController on the Mesh. Sure i could check for this somehow (or simply ignore it) but i don't think that it's worth it ATM.

[raft]

if you say so..  :roll:

[EgonOlsen]

I promise that i'll look into that topic once again if i find the time. But i can't promise that it will lead to something... :wink:

[raft]

if you say so..