3D help?

Hello everyone!
I'll try to make it short:
I'm making a 3D grid in Texer-II, and distance between centers of particles is constant (25 pixels).

So on ini/beat it calculates vertical and horizontal steps:
stepx=25/w;stepy=25/h;

Than on point it creates a grid like this:

x1=if(above(y1,1),x1+stepx,x1);

y1=if(above(y1,1),-1,y1+stepy);

...And that transforms to 3D.

So my question is: how do I calculate "n" variable based on width and height? I tried using this:

n=ceil(2/stepy)*ceil(2/stepx);



(number-of-vertical-steps)*(number-of-horisontal steps)

...but that doesn't work correctly 🙁

Any ideas?..

The way you would want to do it is base something off the pixel height. I didn't actually look at your code, but my best guess would be to use something like

n=(h/25)*(w/25)

I don't know if that works either, but it's worth a try. You should also probably calculate stepx and stepy perframe not just ini/beat. You might be coming up with problems in rounding your numbers, since n works as a whole number, (or something like that), if your number of points comes up as say 23.7, it may not work right, it would depend on the preset.

/added/
Also, when making a grid you should not only reset you calculated points (x1,y1) to -1 in perframe, but you should set them to

x1=-1-stepx 

and 

y1=-1-stepy

or you might have to use 1+step, it depends on which way you are drawing your grid.
/added/

Look:

 ____________________ ____________________

|                    |                    |

|                    |                    |

|                    |                    |

|                    |                    |

|                    |                    |

|                    |                    |

|                    |                    |

|                    |                    |

|                    |                    |

|____________________|____________________| 20 steps, 25 pixels each

|                    |                    |

|                    |                    |

|                    |                    |

|                    |                    |

|                    |                    |

|                    |                    |

|                    |                    |

|                    |                    |

|                    |                    |

|____________________|____________________|

         20 steps, 25 pixels each

20x20 = 400 points/particles
20x25 = 500 (height/width)
SO, how do I convert 500x500 to n=400? 😱

Your variant (yes it is correct as theory): (500/25)*(500/25)=400

BUT practicaly it doesn't work 🙁
There should be something wrong with my scope. Can someone look at the code? Pleeease?

P.S. yes, it's already got "y1=-1-stepy" and "x1=-1-stepx" stuff 😁

n=floor(w/25)*floor(h/25);

suppose:
w=500
h=500
gives you 20*20=400

You need to use an image that you know the dimensions of and use that to calculate n. Like this.

[edit]
UIUC85:I tested your solution,It makes things worse.
[/edit]

That's because his logic is wrong. You based your steps assuming that the particles are placed in terms of height and width and not in cartesian coordinates. Honestly I dont know why you are setting it up like this anyways if you are just going to add rotation. If you really feel the need to try and plow through this mess you need to set up your step like this.

stepx=(2/w)*25;
stepy=(2/h)*25;

Then you can use the equation I gave you before to get the correct n value. But with this idea you are using, you are going to have to center it and what not... It's just a hassel if you ask me. If you want my opinion you should just arbitrarily set the dimensions of your grid. That would make a lot more sense and it would mean less work and cleaner code.

UIUC85:Your n solution doesn't work at all. Try Copy&Pasting it into his preset and removing his logic. It screws the preset up.

My n solution and his logic work fine with rotation. Look, here is a rotating version using my n solution.

And please try to be specific in who your are talking to. If you have a problem with the grid please don't blame it on me.

Here, you want me to explain it for ya? It's not just copy and paste. What he has isn't going to achieve what he wants. He's based his system off width and height instead of using cartesian coordinates. In order to keep the distance 25 pixels you have to know the cartesian equivalent of 1 pixel for both width and height. SO:

x pixel = (2/w)
y pixel = (2/h)

NOW, he wants it move 25 pixels per step so you multiply the value for 1 pixel by 25!

stepx=(2/w)*25
stepy=(2/h)*25

That will give you the cartesian distance for 25 pixels. So the original problem was finding what value of n would fit the maximum particles into the screen right? So in order to find the how many times 25 fits into the screen both on the x and y axes you take w/25 and h/25. Now depending on whether you want to go a little larger or smaller you can use floor or ciel but:

n=floor(w/25)*floor(h/25)

Now in order to fix his code such that this idea will work he's going to have to go through a lot of it and change stuff and I'm not willing to put in that effort. No thanks. Realistically speaking, this 25 pixel distance idea is just dumb. As soon as you add rotation to this grid the whole concept of distancing them 25 pixels apart really means absolutely nothing to the actual look of the grid. Just arbitrarily set your values for the dimensions of the grid and rid yourself of these ridiculous issues.

Hungryskull, mathematically, your solution means absolutely nothing. Why are you dividing 25 by the dimensions of the screen??? That doesn't mean anything in terms of plotting particles. And where did n=ceil(w/11)*ceil(h/11) come from? Did you just pick 11 arbitrarily?

/me agrees with UIUC85 that it is easier and better to just set an arbitrary number of points for a grid like this.

Thank you VERY much! Yeah, I re-wrote the preset now it works.

Anytime 🙂