Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Multitexturing for terrain quads?  (Read 2429 times)
0 Members and 1 Guest are viewing this topic.
Offline Harley Rana

Junior Devvie




Java games rock!


« Posted 2003-03-07 02:01:23 »

Hi im working on my first terrain, and its kindof working, but now needs real textures.

Id like to use a texture field, similar to a height field image.  Each pixels color determines the amount of my 4 base textures.
So each vertex in the quad might have different amounts of each texture.  
As im building each terrain quad into a display list, im assuming blending 4 textures over it will be pretty cheap.

Now if this terrain texturing method totally sucks feel free to sugest something better!  me gl nebie Smiley

Thanks heaps!
Harley.
Offline elias

Senior Devvie





« Reply #1 - Posted 2003-03-07 05:21:45 »

Terrain texturing is quite hard to get fast and nice at the same time, but if it helps, I currently use a technique known as texture splatting. More info at

http://cbloom.com/3d/techdocs/splatting.txt

It uses multipass rendering which is somewhat slow and fillrate consuming. Should improve once pixel shaders become common though.

- elias

Offline Harley Rana

Junior Devvie




Java games rock!


« Reply #2 - Posted 2003-03-07 23:58:43 »

on a structure point.  do you think its worth using a quad tree lod?  ( im already using a quad tree for objects, and leaf nodes are terrain )

from what ive read recently, its faster to use brute force, and just have one high quality terrain for each sector.

would you aggree?

the game in mind is pretty much top down view, rotated abit on z axis.  so the field of view is pretty small.

what about just using one large terrain texture, with a detail texture?  i've seen a detail texture make a big difference on terrain.

thanks.


Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline elias

Senior Devvie





« Reply #3 - Posted 2003-03-08 05:58:52 »

If your field of view is small, say some 50*50 metres, I'd definitely go for brute force. However if you need horizon view of your terrain (500-1000 metres view distance), LOD is crucial. The ROAM seems to be a popular choice, I'm using terrain mipmapping as described in

http://www.flipcode.com/tutorials/geomipmaps.pdf

with success. One big texture stretched over the landscape combined with a detailtexture actually gives quite good results (compared to the complexity of implementing it). I started with that and only recently implemented splatting. However, given a small viewing area like yours, your mileage might very well vary, because the simple one texture method gives best results at a distance, while techniques like splatting really improves short distance terrain (and is actually disabled for terrain at a long distance).

- elias

Offline gregorypierce

Senior Devvie




I come upon thee like the blue screen of death....


« Reply #4 - Posted 2003-03-09 03:03:24 »

I will say this - hardware is fast enough to go pure brute force without you noticing. Morrowinds entire terrain system is based on terrain paging of high quality terrain fragments and it worked out just fine. While I myself am a strong advocate for going with ROAM or some of the modified ROAM algorithms, many developers in production shops are still saying that its almost a non-issue unless you're trying to support machines on the low end.

I remain mixed on the topic because its very problem centric. I personally have more problems occluding stuff ON the terrain than I do with the terrain itself (think cityscape with large numbers of irregularly shaped buildings).

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2003-03-09 09:40:31 »

I found that the disadvantages of ROAM far outweighed the advantages for a game - it's just another one of those technology-for-technology's sake things like psuedo-realistic behavioural AI. Complex, very big overhead, and prevents you from easily texturing the landscape in squares and doesn't add very much to a game. My terrain thing was brute force and I thought it looked good enough.

Cas Smiley

Offline gregorypierce

Senior Devvie




I come upon thee like the blue screen of death....


« Reply #6 - Posted 2003-03-09 19:10:10 »

Yep, my experience is the same as Cas'. I started working with ROAM to handle a very large terrain dataset, but what I found was that if I rethought the problem in terms of being sensible about texture pages or simply swapping in high quality texture pages for low quality ones, that it worked better, didn't have bizarre hole conditions, was easier to build tools with which the artist could predict the results, and didn't have me pulling my hair out.

I think ROAM is a nice algorithm and it has some uses in the gov't vis sim world - but I have yet to encounter any practical reasons for using it. I've always found my bottlenecks to be elsewhere.

CLOD terrain is also impractical for many multiplayer situations because you can never predict how the terrain will be subdivided for each player so while player A can see player B, player B cannot see player A. In a peer to peer environment this can be resolved better than if its a server managed environment because the server will be looking in things from yet a different perspective.

At the moment I'm more worried about using imposters for cityscapes than I am with CLODing my terrain. Profiling my application just doesn't suggest that there is any value in doing it yet.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (33 views)
2014-12-15 09:26:44

Mr.CodeIt (23 views)
2014-12-14 19:50:38

BurntPizza (51 views)
2014-12-09 22:41:13

BurntPizza (84 views)
2014-12-08 04:46:31

JscottyBieshaar (45 views)
2014-12-05 12:39:02

SHC (59 views)
2014-12-03 16:27:13

CopyableCougar4 (58 views)
2014-11-29 21:32:03

toopeicgaming1999 (123 views)
2014-11-26 15:22:04

toopeicgaming1999 (114 views)
2014-11-26 15:20:36

toopeicgaming1999 (32 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!