^..^

6th January 2005 12:27 UTC

"texer cube grid" correction
i've been working on some 3D-scope and texer II's during the last weeks and developed my own rotation matrix (guess it looks like every other matrix, but i think its important for understanding to make your own).

However, i managed to code this cute texerII cube, but there are two problems i can't find a proper solution for.

1.) i have the feeling that the cube gets contorted cause of the rotation. so where in the code should i care for the aspect ratio correction, at the end (3D/2D conversion) or on the rotaion matrices?

2.) the second problem is about the size of the balls respectively the size of the gaps between them. how do i mange this size to stay (roughly) the same while the cube moves further away or comes closer?

i hope those question are not too stupid or simple...

Well, this is what i've done so far:

Jaak

6th January 2005 12:48 UTC

1) in the end do y = y * (w/h)
2) i dont quite understand what you mean, but i guess you could change... just use distance between camera and object
you have to move object before rotation, not after it

^..^

6th January 2005 14:00 UTC

thanks for the help

1) but as i presumed y=y*(w/h) does not really work, it looks even a bit more contorted in some positions...

2) my intention was to change the ball-size depending on the z-position. In real life an object gets smaller when its further away. i wanted that the balls grow/shrink correctly when moving towards/away from the screen. Any idea?

What do you mean with camera? (never thought about that) it should be fix point, isn't it? What are my camrea coordinates then?

btw what are the benefits if i shift the cube at first and rotate it afterwards? When i learned "affine mapping" (hope its the correct translation..) in school the formula was like:

a:x = A+x + c (with A: matrix, and c: movement vector)

so why is it better the other way round here?

jheriko

6th January 2005 17:58 UTC

x=x*h/w; and size=(h*.003)/(1+z5/2);

fixes it nicely imo

the size needs to be transformed by the same method as the coordinates to be consistent with them. introducing w/h makes it res independant since the size of the particles is based on the screen height and some aspect ratio correction is applied.

when working with superscopes like this there isn't really a camera whose co-ordinates you know. essentially you are at 0,0,0 looking down the z-axis at a world that moves around you the 2+z or whatever in the projection shifts the whole world by 2 units so that you have the impression of looking at the 'origin'. By doing the rotation first you are rotating the world then shifting its position. The 'camera cordinates' could be got back by rotating the 0,0,-2 vector backwards I suppose... but thats expensive.

When using 'camera code' the idea is to take this method and expand on it a bit. Basically you take the camera coords ox,oy,oz and shift the whole world by them, like x1=x1-ox;y1=y1-oy;z1=z1-oz; then you rotate by the angles you want *the camera* to rotate by, remember that to start with it is looking down the +ve z axis (assuming you are clipping the negative values... otherwise you get ugly line bugs). In essence you are shifting the world and rotating it around the 'camera' to achieve the effect. When doing the final xyz->xy transform you no longer need to shift the z axis since we have already set up a fake camera to setup our viewpoint. all we need to do is x=x1/z1;y=y/z1; or even better (faster) z1=1/z1;x=x1*z1;y=y1*z1; using a camera like this you can move to any point in the world and look in any direction without having to do much head scratching. The problem comes when you want to use 'look at' code, which can often cause gimbal lock if used badly. There are advantages and disadvantages to either method, the main advantage of using a camera is that you can synchronise lots of different types of 3d things together easily.

Jaak

6th January 2005 18:05 UTC

your rotation seems fine to me, i think some ppl call that "distortion" perspective

if you use tiny bit of logic, then you could relize that what greater the distance is, the smaller the object you look is. So, you have to use distance from object to camera to set the size of each particle. Just use the z value

meh, if you want to move the oject in 3D space, then you have to do it before rotation, if you do it after rotation, you just move the picture to left/right or size it (z value). Really depends on what you want to do.

jheriko

6th January 2005 18:50 UTC

got bored and mixed this up to make a cool volumetric thingy...

hboy

6th January 2005 19:15 UTC

werent you from england jheriko? speaking german eh? goddamn sexy cube man. awesome!

^..^

6th January 2005 22:24 UTC

don't wonder about the german comments. i added them when i made the texerII cube which jheriko fixed up a tiny bit ;). I just commented so much on this, so that i can handle the 3D-rotation code better. (which actully is one of my first attempts in this topic).

But maybe if some tutorials/explantions were also available in german i would learn much faster, cause i have to translate everything first, before i can go on and try to understand it...

but. WOW! that's amazingly cool what you've mixed up there... really like that!!

but unfortunately i don't understand some of your additions.

So you optimized the shifting with the "sin"s, ok get that. also you fixed the 3D/2D translation and the aspect ratio correction, get that too. got the "res independant sizing" either.

But what's the technique behind the metablobs, is it that ominous raytracing-thing? (where can i learn more about that? 3d rotation-help lies around everywhere)
Guess the "volumetric effect" has to do with the color-code and therefore has to do with the blobs, but how does it work together? :confused:

So much open questions, hope you can explain some more? would really like to learn more.
but please step by step :)


oh, and jaak, i've tried to use only the z-value for the size change but it looked a bit crappy, so i asked if someone knows some tips and tricks for this.


o.k now i have to re-read jheriko's explanation post. hope that i get it soon... ;)

Jaak

7th January 2005 00:16 UTC

Originally posted by ^..^
but unfortunately i don't understand some of your additions.

So you optimized the shifting with the "sin"s, ok get that. also you fixed the 3D/2D translation and the aspect ratio correction, get that too. got the "res independant sizing" either.

But what's the technique behind the metablobs, is it that ominous raytracing-thing? (where can i learn more about that? 3d rotation-help lies around everywhere)
Guess the "volumetric effect" has to do with the color-code and therefore has to do with the blobs, but how does it work together? :confused:

^..^

7th January 2005 00:30 UTC

do you know what maths is behind it? Mostly i try to understand things in AVS using my math-skills.
So i did with the 3D rotation thing i learned recently. I took three roation matrices, one doing a rotation around the x-axis, one around y and one around z. then i worked out the matrices and got the lines of code for avs.

But what bases the metablobs-code on? It's just to better comprehend it.

PAK-9

7th January 2005 01:11 UTC

Heh thats a wicked mix J. Its actually a bit of a laugh playing with the texer2..

hboy

7th January 2005 08:26 UTC

you codemonkeys feel sooo comfortable now do you :D awesome presets!...errmm...techdemopresets!

^..^

7th January 2005 10:13 UTC

thanks guys... i tried to do something demanding but what happens when i reach my objective? some super-heavy coding experts come along and blow this cube up to something totally incomprehensible. very good job... :hang:


joking apart... cool what can be done with such a basis-scope. somehow paks cube reminds me of some quantum machanics... great work too...

PJ-Avser

7th January 2005 10:15 UTC

Jheriko's mix looks almost exactly like my preset cubation, Except it is mostly blue and pulses. I'm annoyed cause that took ( me ) ages to do and now it's not original. OH well. * goes and changes colour code* ooooh, now it's 3D plasma! I'm not showing you It though, you'll have to download my pack! ;)

^..^

7th January 2005 10:56 UTC

yeah, that's the way it goes! You think you made something special or tried to do something complicated, but as soon as you finish, one of those codemonkeys (nice word hboy ;) ) comes up with something much better... :( bad luck...

well, mostly you can learn something from the codemonkeys, so it's not that bad, at all. :)

Jaak

8th January 2005 11:42 UTC

Math behind it? Its just plain stupid distance calculation,
distance between point (x1,y1,z1) and (x2,y2,z2) can be calculated with:
D = ((x2-x1)^2+(y2-y1)^2+(z2-z1)^2)^(1/2);
or: sqrt(sqr(x2-x1)+sqr(y2-y1)+sqr(z2-z1))
and dont say you havent learned it in school yet?

^..^

8th January 2005 14:01 UTC

yeah, thats clear! thank you for your patience :D
somehow i didn't recognize it...

So the aditional code generates a d-value (polar coords) for each of the four metablobs, which means generating a radius, right? and cause the "px,py,pz" values generated in Frame vary -(time dependent, not framerate dependent)- d1/d2/d3/d4 varies too. in the end it looks as if the blobs move around. but how did he generate the blobs in the color-code only working with d=d1+d2+d3+d4 as variable? that seems illogical to me somehow, cause the four blobs move around freely. They should depend on either d1, d2, d3 OR d4 and not on d1, d2, d3 AND d4 (at least in my imagination).
i hope i haven't infected you with my confusion and you can still explain that second part?

jheriko

9th January 2005 08:01 UTC

there are a lot of ways of doing metablobs. the way i did it makes a finite number of blobs and maintains areas/volumes so that as two blobs merge no 'matter' is created or destroyed, this tends to look best as it simulates the 'real world' a bit better... but its just a matter of taste.

lets start with defining circles and try to work it towards metablobs. Lets say that we do this by finding points that are a set distance away from the circle's centre. we would need something like (over simple):

d1=sqrt(sqr(x-px1)+sqr(y-py1));
d2=sqrt(sqr(x-px2)+sqr(y-py2));
d3=...
d=bor(below(d1,.1),below(d2,.1))+bor(below...

where px1,py1 px2,py2 etc... are the centres of the blobs, and we draw whereever d=1

the problem with this is that no blobbing happens. we need to take into account the distances to all of the centrepoints when working out if we draw a point or not since if two blobs are near then our point may be in neither circle but could be in the blobby mass that joins them. for this reason we need to combine d1 d2 etc to create the metablob effect.

because the distance gets smaller nearer the centre its not the best way to define the boundaries of the system of blobs since we are interested in how close we are to the centres to work out the blobbing, not how far away they are. what might be better is to use 1/d1 1/d2 etc since they are higher at the centre. so we do:

d1=1/sqrt(sqr(x-px1)+sqr(y-py1));
d2=1/sqrt(sqr(x-px2)+sqr(y-py2));
d3=...
d=above(d1+d2+d3...,10);

this creates a metablob effect, its not perfect though.

in a simple system with d1 d2 based on p1x/y p2x/y and d=d1+d2 we can se that if we use above(d1+d2,10) then when p1 and p2 meet the blob doesn't increase in size correctly since for a single blob d1 (or d2) = 10 if the distance to p1 (or p2) is equal to .1 since 1/.1 = 10, but for the two blobs together on the same spot 2/.2 = 10, but our radius has doubled! which means that our area has grown by 4 instead of 2! to fix this we do:

d1=1/(sqr(x-px1)+sqr(y-py1));
d2=1/(sqr(x-px2)+sqr(y-py2));
d3=...
d=above(d1+d2+d3...,100);

then 1/sqr(.1) = 100 and 2/sqr(sqrt(.2)) = 100 and we have the correct new radius of sqrt(.2) for a joined blob

^..^

9th January 2005 12:06 UTC

many thanks!!
i won't understand everything straight off, but i'll proceed step by step...

ok. let me repeat your explanation with my own words. Please correct me when i got something wrong.

at first we have do set the distance of the blob's centers and their outer bounds and taking into consideration that the radius increases when two blobs approach each other.

This way we want to achieve that the variable d tells us if the momentary point is affected by a blob or not.
when we add d1+d2+d3+d4 we add all metablob influences. the resulting sum is the sum of meatblob influence.

the result will be, that d is 0 for a point that is outside of any blob and will increase when a blob gets near. (nearer = greater value for d). Afterwards we can apply d in the color code, then it becomes visible whether a point is affected by a metablob or not.
Please correct me if i understood anything wrong!

but in case it's correct, could you please spent a few words about your color code itself? or how to apply the metablob value to other components in general? many thanks in advance!

^..^

9th January 2005 13:33 UTC

i've just tried out a simple colorcode: color=(1/z4*0.5)*0.1*d together with your metablob code..
and the blobs got visible! so this is clear now. (would still be great to know a bit abour metablobs and other avs-components...

btw now i'm wondering about the time-independant movement you made:

t=t+gettime(lasttime);
lasttime=gettime(0);

why do you write gettime(lasttime)?
"lasttime" gives you the time since last boot, right? but when set as gettime(lasttime) avs will reduce its value to 1 since the time since last boot is always a positive number. So what does your code do?

Jaak

10th January 2005 05:46 UTC

your metablob explanation sounded correct, tho' it isn't really that hard as you made to sound it.
i am speculating that gettime(someothertime) will return time from the someothertime (currenttime - lasttime, i might be wrong tho', correct me if i am), so this is simply fps dependant movement, whatever the fps is, t gets incremented by correct ammount.

^..^

10th January 2005 08:51 UTC

yea, however it works it does what it is supposed to do, but
t=gettime(0)
works just as fine as
t=t+gettime(lasttime); lasttime=gettime(0)
so i was wondering why not use the first code?

At least i now understand the metablob-effect in this grid-cube. :)

UnConeD

10th January 2005 22:39 UTC

Jheriko's explanation that the function has to be "higher at the centre" is not specific enough. What matters for proper 'blobbing' to occur is that the fall-off function is convex (i.e. second derivative > 0, shape goes like ***8899; ) and drops the further you go from the blob.

The attached preset shows what happens when the falloff function is convex, neutral or concave (***8898; ). In the concave case, a bump forms in between, which causes a 'phantom' blob in between the metablobs before they merge.

^..^

11th January 2005 00:34 UTC

i see, but doesn't it HAVE to be that way? i mean the metablobs have to merge into each other in a convex way, because they ARE convex objects, don't they?

to me it was obvious somehow from the beginning, i didn't even think about the whole convex,concave,linear thing... ;)
But you're right, one could think of a different/wrong "gradient" when you read "higher at the centre and lower at the boundaries".

btw i'm playing around a bit with the technique and i wanted to know where it's best to combine the metablobs-value with? It also works with the color-code of ssc's and i tried to do some blending with the blobs (combined it with "alpha").... just curious if there's anything tricky about it?

jheriko

14th January 2005 22:11 UTC

i use gettime(lasttime) as a bad habit. normally i do dt = gettime(lasttime) and use that for stuff... i just don't think a lot about the routine things...

the 'correct' way to do blobs is to sum the inverse squares of the distances like in my code... it maintains the volume/area of blobs making it look like no material is magically created or destroyed.

working it out before you set red green blue or whatever is usually a good way to it. all you have to do is make sure that you work it out based on the right co-ordinates... so if you rotate a 3d scene you work out the sum before rotating the points.