Did we achieve triangle/vertice lit recognition?

Blitz3D Forums/Blitz3D Programming/Did we achieve triangle/vertice lit recognition?

puki(Posted 2009) [#1]
Did we achieve triangle/vertice lit recognition; ie determining if a triangle (or even vertices) are affected by a DX light (ie lit)?


_PJ_(Posted 2009) [#2]
I think people have been experimenting with per-pixel light (shaders) so they've "skipped over" just looking at the entire vertex.

I dug this up and blew the dust off, though.. Not sure how helpful it might be:
http://www.blitzbasic.com/Community/posts.php?topic=68345#764889


(EDIT - Within that discussion was a link to this in the archives:

It's a workaround to simulate lighting by using Vertex Colour
http://www.blitzbasic.com/codearcs/codearcs.php?code=284

)


puki(Posted 2009) [#3]
I want to do a more realistic lighting system:

This is what I have so far - may seem a bit dark:


Basically the table which has the candle on it is only top-surface lit. I have stopped the light hitting the base of the table. Normal DX lights pass through surfaces.

The base of the table to the right is lit by the candle.

I'm kind of interested in how people would go about doing what I did.


Ross C(Posted 2009) [#4]
My own way would to probably use a ray pick from the physics engine. Limit the length of the pick firstly, to the lights range. The problem is see though, is it's not a great real time solution, if the light is moving...

The problem with the ray pick, is you would need to do thousands, and it would be probably quicker to do real time lightmapping.

It's a tough one. That's probably why the other methods are being used tbh.


puki(Posted 2009) [#5]
Clue: I separate meshes as far as they will go.


Ross C(Posted 2009) [#6]
I have no idea how you did it. Perhaps rendering all the dark parts first, preserving the z-buffer, then rendering all the lit parts? I'd like to see a light moving though, and the lighting actually updating to miss out the shadowed areas.


puki(Posted 2009) [#7]
The table base cannot 'see' the light.

If you separate a model into various sections you can know which sections can 'see' the light. You can map sections together to globally recognise light recognition.

However, to 'see' is not just to visually 'see' - the physical location of a light can prove it as 'unseen' based on the location of what could 'see' the light.

Note:
This is all done with one pass - only one render.


GIB3D(Posted 2009) [#8]
Couldn't you simply stop the raycasting at a certain distance so it doesn't have to calculate as much? I don't know if that's how it's already done or not but.. just seein if it helps.


puki(Posted 2009) [#9]
The picture posted is using my lighting system. I was trying to find out how people would achieve it.


You can kind of do this using this: http://www.blitzbasic.com/Community/posts.php?topic=75711

BP_SetLightMaxRange%( light,range# ) : "SetLightMaxRange@8" ; sets absolute LightRange ( not normally accessable in b3d )

However, I did not.


Kryzon(Posted 2009) [#10]
Where can I read about those "not normally accessable in b3d" light functions, like that SetLightMaxRange and the others?


puki(Posted 2009) [#11]
Probably in the SDK: http://bcb-tools.com/Downloads.htm#DirectX7


Kryzon(Posted 2009) [#12]
Gee, thanks Puki!
I didn't even think there was the Dx7 SDK available for download anymore.


_PJ_(Posted 2009) [#13]
Nice to know those BP functions work. I use BPlus myself, but havent gotten to the more techy light stuff yet.


Anyway, I will say I think your table is very nice. One of the biggest problems with the 'default lighting system' is where light passes through objects.

The problem with the ray pick, is you would need to do thousands, and it would be probably quicker to do real time lightmapping.


There might be some way to optimise this, because at the first sign of any 'obscurer' and across the profile of the obscurer, EVERYTHING behind the obscurer will be unlit.
The maths and stuff to figure that out tho is way beyond me.


puki(Posted 2009) [#14]
Bare in mind though that, prior to "Billp's" goodies, you could bypass the limitations with LightMesh - ie, for example, you can contain lighting within a room - not just a sort of static lightmap lighting, it can be dynamic - ie be moving, be multiple lights, be casting on moving entities within the room, etc.

That table could be done with a LightMesh call that is exclusive to the table top and the other tables - ie, everything but the base of the table that the candle is on. However, the light in my pictured example is a CreateLight(2) and the LightRange is set to .4; However, .4 is enough to hit the base of the table - which is, in fact, what is actually happening.


ShadowTurtle(Posted 2009) [#15]
yeah... this are the good ol' 3d effects \o/

erm.. this normaly knows only map/model designer eh? ok.. a good 3d engineer too..

back to topic: today you can realy create worlds with 20000 triangles per scene. With this rate is good looking vertex lighting (CPU&GPU) no more a problem. In these terms i am with blitz3d up to date Oo

Thanx puki!