PDA

View Full Version : If Then Else in Expressions?



bradl
07-29-2003, 08:13 AM
I have an expression cos(rad([Camera.Rotation.B]+90)) for a channel Light.Position.X

I want the Light.Position.X to remain at 0 until the Camera.Rotation.B input is greater than 180 or less than 360. In other words I don't want the expression to be applied until the Camera reaches 180 degrees of rotation up to 360.

Here is what I want to do in plain English:
If Camera.Rotation.B > 0 but < 180
Then Light.Position.X = 0
Else Light.Position.X = cos(rad([Camera.Rotation.B]+90))

Can I do something like this in an Expression?

Do I need an LScript, and if so, how do you apply the script to a specific channel?

Thanks,

bradl
07-29-2003, 08:18 AM
Ok, I saw there was an LScript Channel Modifier plug-in if I need to got that route...

Lightwolf
07-29-2003, 08:23 AM
Hi bradl,

try this:

(([Camera.Rotation.B] > 0) && ( [Camera.Rotation.B] < 180 )) ? 0 : cos (rad ( [Camera.Rotation.B] + 90 ) )

Lightwolf
07-29-2003, 08:27 AM
bradl:
The "&&" is a logical "and".
So basically:

if Cam.Rot.B > 0 and Cam.Rot.B < 180
? then return 0
: else return cos rad whatever...

Cheers,
Mike

bradl
07-29-2003, 08:50 AM
Lightwolf,

Thanks for the quick response. It worked just as you said. However, if the camera goes past 360 (i.e. back in the 0 to 180 range) it keeps on processing the cosine. Is there a way to limit the high value on rotation in this expression?

Maybe another expression that converts the camera range of rotation values to 0 to 360 substituted for my camera channel value?

Thanks again,

Lightwolf
07-29-2003, 08:55 AM
bradl:
I suggest you browse through the expression builder:

clamp([Camera.Rotation.B], 0, 360)

You'll have to insert it twice though, or create a new expression with the above line, let's call it ClampCam, and replace the
[Camera.Rotation.B]
with
[ClamCam]
in the old expression.

Cheers,
Mike

bradl
07-29-2003, 08:59 AM
Cool...

I was just thinking they would have a function to return an angle no matter how many rotations.

You have been a great help. I have lots more work on the expression(s) but this has got most of the way there. Thanks, again.

Brad

Lightwolf
07-29-2003, 09:08 AM
Hi bradl,
You're welcome.

You're right, it would be nice to have a Wrap() function that does just that.
Actually, with a bit of LScript and the new lscript library for expressions that could be done quite easily.

It would basically act like the clamp function
Wrap(input, a, b)
if input > b
while ( input > b ) input = input - (b-a)
else if input < <
while ( input < a ) input = input + (b-a)
return input

Something like that (this is just pseudo code...)
Cheers,
Mike

bradl
07-29-2003, 09:11 AM
Adding clamp (had to put it at all three instantances) did the trick. I may actually finish this up today!

Lightwolf
07-29-2003, 09:13 AM
You should, it's 5:00 pm over here :)
You should be glad you're in Texas, you have more time to finish...
Cheers,
Mike :p

garg
07-29-2003, 12:19 PM
to make the number "wrap" you just need to use modulo

mod(x,360) will return always a number between 0 and 359.999999 at 360 it will give back 0. So this is what you need :-)

Alain Bertrand

bradl
07-29-2003, 01:30 PM
Mike,

At first I didn't notice the Conditional Statements in the Expression Builder. So now I see where you got the If Then Else syntax. But where did you get the && from for and?

I would have never guessed that and they don't list it. In fact the docs on expressions (not the builder) don't mention half of what's available. Is there a better source for documentation?

The expressions are now finished and work exactly like I planned, here they are for reference.

ClampCam expression:

clamp([Camera.Rotation.B], 0, 360)

ShadowLight.Position.Y:

(([ClampCam] > 0) && ( [ClampCam] < 180 )) ? 0 : (cos (rad ( (2*[ClampCam]) + 90 ) )) * .225

note: scaled down to high and low of 255mm (1m is default)

ShadowLight.Position.X:

((([ClampCam] > 0) && ( [ClampCam] < 180 )) ? 0 : (cos (rad ( [ClampCam] + 90 ) )) * .180) - .225

note: scaled the results (180mm) and added an offset (-225mm)

bradl
07-29-2003, 01:31 PM
Alain,

I remember that from trig class...

Brad

Mylenium
07-29-2003, 11:52 PM
The && just like || or != are logical operators common to most programming languages. You may find out more about them just by finding yourself some info on C or Java on the web. Personally I would love to see Expressions/ LScript be more like Java instead of having to use sometimes rather strange constructs in a C style manner.

Mylenium

garg
07-30-2003, 12:14 AM
Well it make sense to have a C like structure, because all the SDK is meant to be used in C, so if you start your project in LScript, you should be able to translate it without too much pain in C.

At least, this is how I see it.

Alain Bertrand

Lightwolf
07-30-2003, 02:07 AM
Alain,
I agree. The same goes for LScript as well (Expressions and LScript should be merged anyhow...)

The main problem I have with LScript is the fact that the line between the language and the LW API isn't really well defined, especially not in the docs.
I find it quicker to hack something together in C than in LScript :(

Cheers,
Mike

garg
07-30-2003, 03:06 AM
Problems with SDK docs are also my main complain... I think the SDK and the LScripts docs are not up to pair.

But anyway, it's still possible to add a lot of functionalities, even if sometime I spend days figuring how to get/do some specific things...

Alain Bertrand

Lightwolf
07-30-2003, 03:12 AM
garg:
The SDK docs are pretty good imho (at least they were as long as Ernie was in charge of them), the LScript docs a sub par, I have to agree.
Let's wait and see what [8] brings, there are still loads of key areas where we have to either re-code internal functions or find ugly workarounds...
Cheers,
Mike

garg
07-30-2003, 03:35 AM
No... I think also the SDK doc is dub par... look, if you need to code something like a procedural shader, there is no clear documentation:

http://www.newtek.com/products/lightwave/developer/75lwsdk/docs/classes/texture.html

And all you need to do is look at the example and try as well... (I mean for the interface part)

Also look a the description of the tree control :/ you always end up reading some c sample. BTW I found also quite a few bugs in the SDK and the SDK doc... which is not what you want...

Real to start creating the LW SDK you loose a lot of time...

BUT as I said, I normaly manage to do what I need... so at the end (with lot of efforts) you can do more or less what you want.

Alain Bertrand

Lightwolf
07-30-2003, 03:54 AM
garg:
I might not be that critical as far as the SDK docs are concerned, since I started with the 5.6 docs, and they were a major pain (just a couple of mixed up pages).
Also, looking at other SDKs, the LW docs aren't that bad in comparison. Still, a lot of trial and error is needed, and there are some bugs (like LWSYS_SERIALBITS not working as expected in Modeler).
But at least there are a bunch of samples to learn from :)

Cheers,
Mike
P.S. we're going seriously OT here. Should we start a new thread on the SDK, and improvements we'd like to see?