Light.. back the Normal
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 29/06/2006 at 05:11, xxxxxxxx wrote:
Any help to how make RayLightComponent::lv and RayLightComponent::col valids for light back to the normal?
Thanks
Renato T. -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 03/07/2006 at 07:40, xxxxxxxx wrote:
No idea, but... the manual says RayLightComponent::col is the color of the lightsource. So, how about using raylight->light->color ?
If calculating the lightvector works for you, i guess it's okay.. -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 03/07/2006 at 10:31, xxxxxxxx wrote:
I'm very sorry for the delay. I will look into this issue immediately!
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 03/07/2006 at 10:41, xxxxxxxx wrote:
With 9.5+ there is a new field IlluminanceSurfacePointData::cosine_cutoff that seems to control this behaviour. With 9.1 I assume this means that cosine_cutoff == TRUE always. So your solution seems to be correct in 9.1, though it might be worth to see if the cosine_cutoff code is faster on 9.5+.
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 03/07/2006 at 11:16, xxxxxxxx wrote:
Thanks Mikael,
This mean that with the 9.1 sdk i must calculate the light vector and the light color myself?
Sometime with manual calculation of these vector i get zero for color...
Anyway seem that with the 9.5 this issue can resolved
Thanks for your answer
Thanks Michael too.Cheers
Renato T. -
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 08/07/2006 at 04:24, xxxxxxxx wrote:
Yes, I just got a reply from the developers that the only way in 9.1- is to flip the ray offset and vector (along with cosc) if it's on the wrong side.
-
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