Terrain issues

Archives Forums/Blitz3D Bug Reports/Terrain issues

Axel Wheeler

(Posted 2008) [#1]

I know some of these terrain issues have been discussed periodically, but I don't see any mention of them here, so here goes:

1. Terrain x & z sizes are wrong

A 128 x 128 terrain for example appears to display vertexes 0-128, which is actually 129. However, 0 and 129 seem to be the same vertex showing up at both sides. There are workarounds (e.g. zero the entire border), but I wonder if there is an official recognition of this and perhaps a statement on whether it will be fixed. I'm assuming it's not intentional...

2. Terrain height is not a float

ModifyTerrain takes a value from 0-1 for the height, but this seems to be resolved to a fixed number of 'levels'. This creates an unpleasant terracing effect when terrains are scaled too high. (Hence the 'tip' not to scale terrains too high, without any mention why...)

This may be the intended behavior although I don't see it documented anywhere, and the documentation stating it is a value from 0-1 seems to imply a float. Am I just doing something wrong?

If not I'd call it a bug if the documentation and behavior don't match.

What is the actual number of 'terraces' available?

Is there a list somewhere of the actual values, or a method to calculate them?

Is there a plan to increase the number of terraces at some point?

And one more thing... thanks for a great product.

Stevie G

(Posted 2008) [#2]

1. It is intentional but Blitz Terrains are not very versatile - use mesh terrains instead.

2. The terrain height when creating from a heightmap image is determined by the red component of the pixel colour, therefore only 0-255 steps/terraces are available.

Axel Wheeler

(Posted 2008) [#3]

Thanks for the reply.

Yes, I realize that with heightmaps it must translate the byte value into the float. That's not what I'm talking about. This limit exists even when using CreateTerrain() and then ModifyTerrain(), which is what I do. I just want to be sure this is the known behavior in these cases as well.

I can't sleep, so I just wrote this demo of the issue.

;*** ModifyTerrain() Test
;*** by Peter Freedman

Graphics3D(800,600,32,2)
SetBuffer(BackBuffer())

;*** Globals

;*** Lights
light1=CreateLight()
LightColor(light1,200,150,100)
RotateEntity(light1,45,-45,0)

;*** Camera
cam=CreateCamera()
PositionEntity(cam,3,0,-30)
TurnEntity(cam,20,0,0)
;*** Sounds

;*** Action
terrain=CreateTerrain(8)
TerrainDetail(terrain,4000,1)
TerrainShading(terrain,1)
EntityColor(terrain,0,0,255)
ScaleEntity(terrain,1,500,1)

pointer=CreateCone()
RotateEntity(pointer,0,0,-90)
EntityColor(pointer,255,0,0)
PositionEntity(pointer,2,0,3)

tpointer=CreateCone()
RotateEntity(tpointer,0,0,90)
EntityColor(tpointer,0,0,255)
PositionEntity(tpointer,4,0,3)
height#=0

Dim altitude#(1000)
altitude(0)=0
terrace=1
Log$=Chr(10)+"Allowable Y-values in Blitz3D Terrains using ModifyTerrain():"+Chr(10)+Chr(10)+"Terrace, TerrainHeight"+Chr(10) 
While Not KeyHit(1)
	;*** Entity Stuff
;		If MouseDown(2) Then height#=height+.0001
;		If height#>1 Then height#=1
;		If MouseDown(1) Then height#=height-.0001
;		If height#<0 Then height#=0
		height#=height+.0001
		ModifyTerrain(terrain,3,3,height#)
		PositionEntity(pointer,2,height#*500.0,3)
		PositionEntity(tpointer,4,TerrainHeight(terrain,3,3)*500.0,3)
		PositionEntity(cam,3,height#*500.0,-30)
		If TerrainHeight(terrain,3,3)<> altitude(terrace) 
			terrace=terrace+1
			altitude(terrace)=TerrainHeight(terrain,3,3)
			Log$=Log$+terrace+",       "+TerrainHeight(terrain,3,3)+Chr(10)
		EndIf

	;*** Check for Collisions and Do Animations
	UpdateWorld()
	
	;*** Draw to the Screen and Do Tweening
	RenderWorld()
	;*** All 2D stuff goes here
	Text(400,40,"Difference between ModifyTerrain() values and resulting TerrainHeight() values",1)
	Color(255,128,128)
	Text(60,150,"ModifyTerrain(terrain,3,3,"+height#+")")
	Color(128,128,255)
	Text(450,150,"TerrainHeight(terrain,3,3)= "+TerrainHeight(terrain,3,3))
	Color(255,255,255)
	Text(450,170,"Terraces so far= "+terrace)

;	Text(0,100,EntityY(cam))
	;*** Flip the Graphics Buffers
	Flip()
	
	If terrace>255 
		savefile("terraces.txt",Log$)
		End
	EndIf
	
Wend
End

;*** Functions
 Function savefile(filename$,Log$)
 	fileout=WriteFile(filename$)
 	WriteString(fileout,Log$)
 	CloseFile(fileout)  
End Function

It will also spit out a list of the allowed values into whatever directory it is saved in.

Thanks again.

Zeotrope

(Posted 2008) [#4]

So if this is a bug....and it sounds as if it may be, wouldnt a fix (wish list# 33323005) give the following terra height available values?

255*255*255? [r g b]
(16.8 million heigh varaitions?)

If not....what would the fix be capable of doing? Consider that it could be a documentation error alone.

All in all, another good reason to move to mesh based terrain. Sad but true.

Floyd

(Posted 2008) [#5]

Both are intentional, but I don't know if this is documented anywhere.

For issue #2, height values are stored in a single byte. Thus a maximal terrain, 2048 x 2048, needs "only" 4MB of memory.

I know that issue #1, the "wrap around" of height values at the edges, is also by design as this was mentioned years ago. But I don't recall any explanation of why this design choice was made.