Technopolies

[rolz]

- added die animations
- added some UI elements

[Remo]

Seems a lot better. But I couldnt run it . Connection exception. I was wondering if theres a newer client or something.

[rolz]

is available at
http://home.ripway.com/2005-5/312079/techno_2005-07-03.zip

[Remo]

Aw. Im getting a connection refused exception. Do you think this is due to my conection or is the server down sometimes?

[rolz]

Strange, just checked the server, it's up and running.

The server's IP was changed to 212.98.171.182, but it should work fine if you downloaded the latest client version.

[Remo]

I used command line with the old ip. I bet its that. Checking now.
Edit:

[rolz]

oh i see. Running 3d.bat without parameters means localhost, that's  why connection refused. I will remove it in the upcoming demo, just use run.bat instead.

btw, new features are scheduled for tomorrow's demo:

- added auto generated transitions between ground textures
- new look for trees

[Remo]

oh i see. Running 3d.bat without parameters means localhost, that's  why connection refused. I will remove it in the upcoming demo, just use run.bat instead.

Didnt work neither . I think it may be Norton firewall or something like that.

btw, new features are scheduled for tomorrow's demo:

- added auto generated transitions between ground textures
- new look for trees

Great! I want to see those

[rolz]

It's been very quiet in the forum lately. Things are not much different with technopolies, i dont recall a noticeable thing that was done in the last two months


To give a push, i'd like to share some ideas and code from technopolies (as long as Helge doesnt mind me blogging here


1. Terrain generator.

The common concept for landscapes in technopolies was in
- making it easy to edit (drawing landscape map in photoshop with a couple of brush strokes)
- making it lightweight enough to be transfered via network (~4kb for a 1000 x 1000 meters level)
- make it possible to be divided into regions (to define footstep sounds for different tiles, add effects like sand smokes and animated grass )
- load / render only visible parts of a bigger level


1. Tiles. It seems natural to split big level into smaller rectangular tiles.  A 1000x1000m level could be interpreted as a Object3D consisting of 100x100 tiles (10x10 each).  The code generates an object consisting of 100x100 rectangles

Code Select Expand


@todo


2. Relief. The main idea is to adjust tiles' heights according to some "heights map". The "heights map" is a grayscale image, where color corresponds to some height value, e.g. white = 50m height, black = 0m.  For a 1000x1000 level consisting of 100x100 tiles the grayscale image should be 100x100 - each pixel corresponds to 1 of 4 single tile vertex.

Code Select Expand


@todo


3. Textures.  The idea is that there could be several terrain types on a single level - like sand, grass, dirt, rocks, roads.  Assigning a single huge texture to a whole level might pass for small levels but is not applicable for big ones - due to low detalization and huge texture size.  
The solution is to use a "texture map" image that defines texture per each tile.

Let's bind some colors to specific textures, let's say green corresponds to "grass.jpg", yellow - "sand.jpg", brown - "dirt.jpg", etc.  Then, paint a 100x100 image in photoshop using green, yellow and brown brushes. For a 100x100 tiles level, assume that 1 tile corresponds to 1 pixel of the "texture map". Pixel's color will define what texture file should be used for this tile

Code Select Expand


@todo


While textures look detailed, transitions between tiles of different types are still rough. Let's smooth transitions from one tile type to another (jpct107a or newer is required).  Let's take several basic texture types and generate "gradient textures" for each combination on tiles.

First, create RGBImageFilter that generates Image from 2 different tile types (let's say something different between dirt and grass) depending on % of each tile (say, 10%dirt 90%grass or 70% dirt 30% grass).
Generate several gradient textures for each combination of tiles.

Code Select Expand


@todo


Then add some method that will pick closest texture depending on the requested color.

Code Select Expand


@todo


In photoshop, apply Gaussian Blur to the texture map to smooth transitions between different tiles. Looks much better now.

[Remo]

Its looking great!!!!
About not rendering the whole level but only the visible parts, How do you achieve this? Do you use like a dummy sphere or something to get a visible area?

[rolz]

quadtrees. The work is still in progress, an is of low/normal priority.

Basically, i did not find a better idea than to split big rectangular level into several regions and generate 3d terrain when player approaches the border of a region. I hope to add better implementation if i have new ideas

[rolz]

finally. available at
http://home.ripway.com/2005-7/356549/techno_2005-07-19.zip

(edit: added fine JVM tuning settings to the batch file.)

new :
- smooth texture transitions
- inventory and chat UI sketches

todo:
- add autoupdate capability (proprietary or jws not sure though)

some shots

[EgonOlsen]

The texture transitions are very well done. How much texture data does this approach produces?
Using OpenGL acceleration for AWT is a bad idea at least on my machine (WinXP, P4HT, Ati X800XT-PE), because it flips RGB to BGR (i.e. the loading screen is blue and the character screen brown (with a blue body)) and the VM crashes hard when i'm clicking into the chat window. It works fine using the normal AWT pipeline. Why are you limiting max. memory to 64MB? Isn't that a bit on the short side?

[rolz]

nice to see you back

for 4 type of terrains ( dirt, rocks, grass and sand),  and 10 levels of transitions 62 textures were generated. I used 64x64 images for tile textures.


I expected the opengl pipeline to give performance boost for 2d UI elements which use transluency and antialiasing. I did not encounter issues you described - only on older hardware with integrated 3d card (certainly not your case ).  I will need to include it as an optional flag.

regarding the memory flags - just tried to make this stuff to run on an old box with 128mb ram and it went pretty smooth - not superfast but without hickups. It is ok to remove -Xm.. flags at all unless no OOM errors occur

[EgonOlsen]

nice to see you back

for 4 type of terrains ( dirt, rocks, grass and sand),  and 10 levels of transitions 62 textures were generated. I used 64x64 images for tile textures.

I was never gone. :wink:
So that means around 1MB of textures...that's not much, i thought it would require more.
I noticed some jPCT/AWTGLRenderer related problems in your client and i spent some time today to get rid of them. I've uploaded a new version that includes this fixes here:

http://www.jpct.net/download/jpct107a2.jar

Changes are:

Fixed a threading issue in the AWTGLRenderer when changing the FOV. Added the option to blit into the backbuffer. This is a fix for a problem that occures when one tries to blit into the background of a over-/undersampled framebuffer. Added on option to modify sorting order of the VisList. Can be helpfull in case of sorting issues with transparent objects. Added on option to Loader to disable vertex sharing (helpfull for loading otherwise unusable keyframes in some cases). Added a new constructor to Texture to create Textures directly from Images. Improved texture loading a little bit.
Some fixes for the AWTGLRenderer: Fixed an occasional class cast exception when setting RGB-Scaling. Fixed a stupid bug that caused green color values to be mapped to green and blue when rendering (i can't believe that this one remained unnoticed). Modified frustum handling to cover a problem that could occur if two or more frames lie between two actually painted ones and the fov has been changed in between. Fixed a bug that prevented the command queue from being resized when needed in some cases which could result in some polygon missing for a frame or two. Fixed a bug that caused queued commands to be removed from the queue in some cases.


However, there still is a problem which i couldn't get fixed and i'm at a point where i'm having my doubts that's its reason can be found in jPCT but in the client. The problem is: Trees are flickering/disappearing (not sure what they really do) sometimes for a frame. I'm not talking about the "normal" sorting problems on transparent objects...this must be something different. To me, it looks like a kind of threading problem (because i had this kind of problems myself on hyperthreading/dual cpu machines). I'm just not sure if it's located in my code (i doubt it because it seems to affect trees only) or in yours. Are you by any chance doing some matrix/object/world/...-manipulation in a different thread than the one that executes the calls to World.renderScene() or World.draw()? Or in other worlds: Is there a chance that rendering and manipulation of the scene and/or objects interfere sometimes?