jheriko

25th September 2002 22:48 UTC

Synching SSC and DM
I can't seem to figure out how to do even a simple SSC and DM synchronisation. I've tried just plain copying the 3d transformation out of the superscope that I want to synch with into the DM but the rotation axes seem to have a mind of their own even after restarting the preset, i cant figure out whats wrong :(
(I also don't wan't to give to much SSC code away ;))

Can somebody around here do me a big favour and give a very simple example of synching a dynamic movement plane to a superscope?

Say, drawing SSC x=0;y=0;z=2*i-1; and DM x=x;y=y;z=-1; so that it looks like the scope is touching the dm plane.

This has been infuriating me for ages now so any help will be appreciated.

Jaheckelsafar

26th September 2002 04:06 UTC

Never tried it myself, but isn't it just a matter of using getosc and getspec instead of random numbers?

jheriko

26th September 2002 07:58 UTC

I have 10 synched superscopes in the preset that I want to have the synched DM in, they all run fine and when making a fake plane in superscope that draws in the right place. The DM is synched in a certain way (like when it moves it moves at the same time and speed) but it always moves/rotates in the wrong direction and in a seemingly random fashion at times.

jheriko

26th September 2002 09:13 UTC

Okay. Here is a part of the preset that I'm trying to make work so that you can see what I'm doing and hopefully be able to tell me why it isn't working.

It uses a render/picture for demonstration purposes, you can put any picture in there, as long as it enables you to see the dm at work.

It is meant to look like the superscope is attached to the dm plane.

jheriko

26th September 2002 11:56 UTC

AAAAARRRGGGHHH!!!!

I figured out what was really screwing it all up, I was using a really crap cheaty method in my ssc that can't be transfered across to dm :(

Oh well... I'l just have to make my planar surface out of superscopes instead.

dirkdeftly

27th September 2002 03:21 UTC

FOR CHRIST'S SAKE, DON'T USE GETOSC/GETSPEC FOR RANDOM SEEDING!

*pant pant pant pant pant pant*

Using the getosc/getspec functions is never a good idea because the seeds tend toward 0, which is exactly what you don't want. Use a timer/sine setup like this:

frame:
timer1=timer1+arbitrary1;

beat:
random1=sin(timer1)

Now your random numbers tend to 1 and -1, making your scopes and DMs more active.

As for syncing SSC and DM, your rotations need to be done in reverse on the SSC. So if you're doing xy first, then xz, then yz in the DM, do yz first, then xz, then xy on the SSC. I believe the rotations on each axis on the SSC also have to be reversed (pi/3 radians on the DM becomes -pi/3 radians on the SSC). You'd have to ask UnConeD, tho, cos he's better at it than I am. I'm not at the level (creation-wise) that I need to be syncing SSCs and DMs :/

jheriko

27th September 2002 09:49 UTC

Okay, I *DO NOT* use getspec and getosc for random seeding because like you just said they are sh*t. That has been my opinion for ages, they are there for adding responsiveness and not randomness. The best way to generate a string of non repeating psuedo random numbers is to do:

frame:
a=a+1;

beat:
ran=(largeprime1*a+smallerprime)%somenumber;

Only reason that I really prefer this method to the sine one (which I used to use occasionally) is that it is a faster calculation than sine.

The reason I wanted to make a synched ssc to dm was because I had made a preset with lots of superscope made objects 'rolling' along a plane with others being fixed to a plane, I just thought that it would be nice if i drew the plane itself using a dm rather than ssc since it makes everything look nicer and less wireframe.

jheriko

27th September 2002 13:10 UTC

Thanks for that reversing the order of rotations advice Atero, that made it work! Almost, anyway...

I'm not going to use it for the preset that I intended it for though because I think that it actually looks better with a superscope made plane, it gives it a look of consistency.

There are still a few little clipping issues to work out (if you check out my attachment you can see what I mean) but I made a simple oscilloscope in between two planes that moves around a bit.

dirkdeftly

27th September 2002 15:02 UTC

The sines are only calculated on beat. I seriously doubt it slows down the process any, and the code for it is much simpler.

UnConeD

27th September 2002 22:16 UTC

Actually I do use getosc a lot, but multiplied and modulated so that it's nearly uniform-distributed:

e.g. foo=(getosc(0.3,0,0)*256%10);

jheriko

27th September 2002 22:36 UTC

The thing is that using the (p*a+c)%m method gives a uniform distribution over time, unlike sin and getosc/getspec.

dirkdeftly

28th September 2002 05:26 UTC

Sine just tends towards 1 and -1. Which is what you want, IMHO...

UnConeD

29th September 2002 01:27 UTC

Yeah but since it works onbeat, it's not as handy for per-frame stuff, and you'll have to track a variable for each one you need. Getosc requires no additional storage either.

jheriko

29th September 2002 01:33 UTC

i'm gonna admit to using getosc recently.. it works quite well for rotating 3d objects.

Jaheckelsafar

29th September 2002 06:52 UTC

getosc worked prety well for me on my star. :)

dirkdeftly

29th September 2002 16:29 UTC

Well, unless you're doing rollercoaster-type-SSC's, a sinusoidal generator shouldn't be that much of a burden. Then again, you could theoretically do a uniform distribution from pi to -pi and use that sine....

nixa

29th September 2002 17:49 UTC

if you want getosc to tend towards 1 and -1 thy whith:
var1=getosc(0,0,0);var2=(1-abs(var1))*if(var1,sign(var1),1);

Zevensoft

29th September 2002 18:05 UTC

Did you try raytracing?

jheriko

29th September 2002 19:08 UTC

I sorted it out :)

I'm only just starting to look into raytracing dms.. i cant see any use untill i want to make some dm cubes or something though. Besides isn't a regular 3d projection raytraced?

Zevensoft

30th September 2002 05:39 UTC

Yeah but most people use the standard z=y-2;x=x/z;y=y/z which causes the plane to actually be slanted, and use the wrong texture axis (x,y) when it should be (x,z). This is why raytracing works, because you get the right texture axis for the plane. That's what's so different about DM's and 3D, you use them for texture co-ords, not polygon co-ords.

jheriko

30th September 2002 08:23 UTC

Yeah that makes sense, thats why you need to invert and flip the axes to a dm to synch it with a scope.