Light.. back the Normal
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 08/07/2006 at 06:46, xxxxxxxx wrote:
Hi Mikael,
Can you tell me more? I fear that i don't understand..
Thanks
Renato -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 08/07/2006 at 12:45, xxxxxxxx wrote:
I just wanted to clarify that the current (slow) way that you have already been using is the only way in 9.1-.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 08/07/2006 at 16:18, xxxxxxxx wrote:
Thanks for info... but seem not much slow today
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 17/08/2006 at 21:00, xxxxxxxx wrote:
"is to flip the ray offset and vector (along with cosc) if it's on the wrong side."
Where i can flip the Ray or the surface normal?
I have lc->col = 0 when the light is back..
The raylight->light->color is the color of the light.
The lc-col take in consideration the light cone.. faloff. etc.etc..
I'm sorry but, i don't know how to.Thanks in advance
Renato T. -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 18/08/2006 at 08:11, xxxxxxxx wrote:
Please,
i need to fix this trouble because i can't use the 9.6 sdk and get benefit from cosine_cutoff.
Thanks
Renato T. -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 24/08/2006 at 13:01, xxxxxxxx wrote:
I think all it means is that if you get col==0 you need to redo the call with a flipped vector, so that the light thinks that it's on the right side of the polygon.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 25/08/2006 at 06:45, xxxxxxxx wrote:
Ok, i understand.. but how i can redo the call?
I don't make any call so i don't know how i can re-make the call
Renato
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 07/09/2006 at 14:44, xxxxxxxx wrote:
(Removed some bump messages. Not to be seen as a criticism; by all means keep posting them if I'm slow. I'm terribly sorry for the delay.)
Ok, I see. So you're not calling the illumination function yourself but just looking in the lights returned by VolumeData::GetLight()? In that case, you're right that it wouldn't be remaking the call, of course. But what happens if you add an extra call to IlluminateSurfacePoint(), with the normal reversed, for the RayLights that are wrong in the pre-calculated GetLight() array? Wouldn't you then get the right color? -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 07/09/2006 at 15:17, xxxxxxxx wrote:
IlluminateSurfacePoint it's a 9.6 function. In the new sdk there is also a flag to prevent the normal.
Did you mean Illuminate on the 9.1 sdk?
Cheers
Renato -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 08/09/2006 at 00:08, xxxxxxxx wrote:
Sorry, I only looked back at the 9.5 API. (To my defense, only really 9.6 is supported. The rest is bonus...
But yes, Illuminate() would be my guess in 9.1 then. Perhaps, even if it doesn't give you totally accurate results for <9.6, it will be good enough to fake backlight? (Though I guess not being foreward compatible in rendering results might be bad as well.) -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 08/09/2006 at 00:53, xxxxxxxx wrote:
But i need to get the returned color because i need to take account of light cone, faloff and some others things.
Maybe faster that i make my self this count or another illuminate will no slower my material?Thanks
Renato