NewsForumsCodeLogsGallerySpecsSearch

Hack: Self-Illumination for any mesh

BlitzMax Forums/MiniB3D Module/Hack: Self-Illumination for any mesh

SystemError51(Posted 2012) [#1]
The game I'm making does require self-illumination of certain parts of meshes (you know, looks cool - especially when it's dark).

MiniB3D can't do out of the box. But no more... I created a little hack to achieve just that while you were waiting.

Add this to the top of TTexture.bmx:
Field illumination:Float[4]


This sets up an array of for values.

Next, put this function into TTexture.bmx:
Method SetSelfIllumination(r:Int , g:Int , b:Int, a:Int) 
    illumination[0] = r / 255
    illumination[1] = g / 255
    illumination[2] = b / 255
    illumination[3] = a / 255
EndMethod


This allows you to conveniently set the desired self-illumination color and its brightness on your texture.

Moving on! Insert this after line 1603 in TMesh.bmx:

Local lred# , lgreen# , lblue# , lalpha#


Also in TMesh.bmx, insert this after line 1614 (it will be line 1614 after you pasted the line above)

' If we have a texture, there may be self illumination
If brush.tex[0]
	lred#   = brush.tex[0].illumination[0]
	lgreen# = brush.tex[0].illumination[1]
	lblue#  = brush.tex[0].illumination[2]
	lalpha# = brush.tex[0].illumination[3]
EndIf


With this, self-illumination does not occur without a texture.

At line 1746 of TMesh.bmx, (which it will be after inserting the above) insert this:

Local mat_emission#[]=[lred#,lgreen#,lblue#,lalpha#]


And finally, at line 1752 of TMesh.bmx, insert:

glMaterialfv(GL_FRONT, GL_EMISSION, mat_emission)



After this, you will either have to recompile your module, or recompile the program if you did not choose to use MiniB3D as module.


Here are some example results.

This is MiniB3D rendering a cube (and a plane) without any self-illumination set on the texture (essentially the same as without the hack):




The same program, with self-illumination (all values set to 255) set on the texture:




This is the texture used for the cube:





Here's a little example program (you'll have to replace the file names of the textures with your own)

Import "../minib3d.bmx"

Strict

Local width=640,height=480,depth=16,mode=32
Local rotation:Int

Graphics3D width , height , depth , mode

AntiAlias 4

Local cam:TCamera=CreateCamera()
PositionEntity cam , 0 , 0 , -50

Local plane:TMesh = CreateCube() 
ScaleEntity plane , 50 , 2 , 50
PositionEntity plane , 0 , - 20 , 0

Local cube:TMesh = CreateCube() 
ScaleEntity cube, 10, 10, 10 

Local cubetex:TTexture = LoadTexture("cube.jpg")
EntityTexture cube , cubetex
' -------------------------------------------
cubetex.SetSelfIllumination(255,255,255,255)
' -------------------------------------------

Local planetex:TTexture = LoadTexture("media/shingle.bmp") 
EntityTexture plane , planetex

While Not KeyHit(KEY_ESCAPE) 
	Cls
	
	MoveEntity cam,KeyDown(KEY_D)-KeyDown(KEY_A),0,KeyDown(KEY_W)-KeyDown(KEY_S)
	TurnEntity cam,KeyDown(KEY_DOWN)-KeyDown(KEY_UP),KeyDown(KEY_LEFT)-KeyDown(KEY_RIGHT),0
	
	RotateEntity cube , 0 , rotation , 0
	rotation = rotation + 1
	If (rotation > 360) 
		rotation = 0
	EndIf
	RenderWorld() 
	Flip
Wend



Over and out


ima747(Posted 2012) [#2]
Is this to allow more control than just using fullbright flag on an object, or have I missed some additional benefit? Curious :0)


Kryzon(Posted 2012) [#3]
Thanks for sharing.
It's very interesting, kinda like a local ambient term for each object.

Do you know how it reacts when being lit under different conditions?

PS:
Import "../minib3d.bmx"

I don't know if you know this, but if you manage to pre-build mB3D with MinGW\XCode you can then import it as a module with "Import sidesign.minib3d" which should be much faster to build (since it only compiles your app's code, not the entire module every time).
I think you use Mac OS, right? so you may have to use Build Modules (CTRL+D) with XCode installed, and then do a Rebuild Documentation for the syntax highlighting.

Last edited 2012


SystemError51(Posted 2012) [#4]
I didn't have time to test it under lighting yet, however on my research about this, I found on all occasions that

glMaterialfv(GL_FRONT, GL_EMISSION, mat_emission)


makes any material appear bright regardless of lighting conditions - as this self-illuminates the object (does not emit light as such, but makes it appear as if it were).

I'm working on Windows.

I know I can use the module... I was just too lazy to make it up until now :D


SLotman(Posted 2012) [#5]
You're guys only thinking about 'full bright' - but this can make a mesh darker or lighter - just like an "EntityColor", but applied on a texture base (so you can highlight, or make darker just parts of a mesh)

Anyway, wouldn't changing the "BrushColor" have the same effect?

Last edited 2012


SystemError51(Posted 2012) [#6]
In my tests, "BrushColor" did not have the same effect as that does not make it "emit" light from itself.

My hack has this effect:




:)


ima747(Posted 2012) [#7]
So it's like full brighting a brush, rather than the mesh... very interesting. Pretty specific usage (essentially self illuminated portions of larger entities) but if applied carefully it could be very handy. Anything that has lights on it (airplane, robots, space ships) the "lights" could just be brush points and would be visible even when the rest of the mesh wasn't illuminated... combined with light maps it could be even more effective...


SLotman(Posted 2012) [#8]
Isn't it the same as this...?



In the code above, I set the brush to full intensity, and regardless the ambient light, or the created light, it still appears even in plain dark...

Last edited 2012


SystemError51(Posted 2012) [#9]
No it's not.

Again, this is the important bit:

glMaterialfv(GL_FRONT, GL_EMISSION, mat_emission)


This is having a very different effect on a material.

GL_EMISSION
params contains four integer or floating-point values that specify
the RGBA emitted light intensity of the material.
Integer values are mapped linearly such that the most positive representable
value maps to 1.0, and the most negative representable value maps to -1.0.

Floating-point values are mapped directly.
Neither integer nor floating-point values are clamped.
The initial emission intensity for both front- and back-facing materials
is (0, 0, 0, 1).



Source:
http://www.opengl.org/sdk/docs/man/xhtml/glMaterial.xml

Last edited 2012