Author Topic: Technopolies  (Read 205012 times)

Offline rolz

  • float
  • ****
  • Posts: 280
  • Technocrat
    • View Profile
new shots
« Reply #90 on: July 03, 2005, 07:43:11 pm »
- added die animations
- added some UI elements


Regards,
Andrei

Offline Remo

  • int
  • **
  • Posts: 64
    • View Profile
    • http://www.opsdirector.com/3dart
Technopolies
« Reply #91 on: July 03, 2005, 11:10:45 pm »
Seems a lot better. But I couldnt run it :(. Connection exception. I was wondering if theres a newer client or something.

Offline rolz

  • float
  • ****
  • Posts: 280
  • Technocrat
    • View Profile
new version
« Reply #92 on: July 05, 2005, 08:01:23 am »
Regards,
Andrei

Offline Remo

  • int
  • **
  • Posts: 64
    • View Profile
    • http://www.opsdirector.com/3dart
Technopolies
« Reply #93 on: July 11, 2005, 10:06:43 am »
Aw. Im getting a connection refused exception. Do you think this is due to my conection or is the server down sometimes?

Offline rolz

  • float
  • ****
  • Posts: 280
  • Technocrat
    • View Profile
hm.
« Reply #94 on: July 11, 2005, 11:39:22 am »
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.
Regards,
Andrei

Offline Remo

  • int
  • **
  • Posts: 64
    • View Profile
    • http://www.opsdirector.com/3dart
Technopolies
« Reply #95 on: July 13, 2005, 09:21:56 am »
I used command line with the old ip. I bet its that. Checking now.
Edit:

Offline rolz

  • float
  • ****
  • Posts: 280
  • Technocrat
    • View Profile
Technopolies
« Reply #96 on: July 13, 2005, 10:05:23 pm »
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
Regards,
Andrei

Offline Remo

  • int
  • **
  • Posts: 64
    • View Profile
    • http://www.opsdirector.com/3dart
Technopolies
« Reply #97 on: July 14, 2005, 12:50:23 am »
Quote from: "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.


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



Quote from: "rolz"

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 :D

Offline rolz

  • float
  • ****
  • Posts: 280
  • Technocrat
    • View Profile
ideas
« Reply #98 on: July 14, 2005, 01:05:20 am »
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]

 @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]

 @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]

 @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]

 @todo


 Then add some method that will pick closest texture depending on the requested color.
Code: [Select]

 @todo


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


Regards,
Andrei

Offline Remo

  • int
  • **
  • Posts: 64
    • View Profile
    • http://www.opsdirector.com/3dart
Technopolies
« Reply #99 on: July 14, 2005, 08:23:28 am »
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?

Offline rolz

  • float
  • ****
  • Posts: 280
  • Technocrat
    • View Profile
autogenerated terrain
« Reply #100 on: July 19, 2005, 07:32:20 pm »
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
Regards,
Andrei

Offline rolz

  • float
  • ****
  • Posts: 280
  • Technocrat
    • View Profile
new version
« Reply #101 on: July 19, 2005, 07:36:44 pm »
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

Regards,
Andrei

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11776
    • View Profile
    • http://www.jpct.net
Technopolies
« Reply #102 on: July 19, 2005, 11:43:26 pm »
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?

Offline rolz

  • float
  • ****
  • Posts: 280
  • Technocrat
    • View Profile
Technopolies
« Reply #103 on: July 20, 2005, 01:37:23 pm »
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
Regards,
Andrei

Offline EgonOlsen

  • Administrator
  • quad
  • *****
  • Posts: 11776
    • View Profile
    • http://www.jpct.net
Technopolies
« Reply #104 on: July 20, 2005, 09:09:39 pm »
Quote from: "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 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?