bug in texer?
today i was working on some images to use them with unconed's texer ape. i figured there was always the very right pixel-column missing. not sure if i'm making something wrong or if it's the ape. please help.
bug in texer?
14 posts
maybe you're using more particles than specified in the ape.
i tried it with various scopes and i played around with texer's settings
I recognized this too, thought it was the scope.
just make a border around the image of a couple pixels.. it should work out fine
not in the texer image.
look at this:
x=-1 works, but x=1 doesn't
look at this:
x=-1 works, but x=1 doesn't
Now try this :
(no texer)
x=-1;
y=i*2-1;
Good, now x=1.
Good, now do the same with switched x and y.
It's an AVS bug.
I knew this for some time, thought it's a minor thing...
Maybe the positive sides are shifted one pixel due to the origin point.
(no texer)
x=-1;
y=i*2-1;
Good, now x=1.
Good, now do the same with switched x and y.
It's an AVS bug.
I knew this for some time, thought it's a minor thing...
Maybe the positive sides are shifted one pixel due to the origin point.
Known issue, due to optimizations. Texer processes two pixels horizontally at a time, so if an image extends beyond the right edge and the visible part has an odd amount of pixels, then the last column will be missing. It happens on the left side as well, except that the missing column is on the right side of your particle (hence you can avoid it there by adding a black column of pixels to your texer image).
A fix inside AVS would be to align your dots at even pixels...
x=((((x+1)*.25*w)%w)/w)*4-1
or something like that.
I didn't think it would matter much because of the inherent limitation in the texer system that a particle disappears as soon as its center goes off the screen (hence, its dot would be gone). Using texer particles at the edges tends to be ugly.
I *could* fix it by reversing the drawing direction on the right side (so the cutoff is on the opposite side) and extend the image when loading, so that it has a black column on both sides.
Don't have time for that now though. If I update it I'll also add a scaling feature (optional of course) where it scales the dot positions so the particles move completely off-screen before disappearing.
A fix inside AVS would be to align your dots at even pixels...
x=((((x+1)*.25*w)%w)/w)*4-1
or something like that.
I didn't think it would matter much because of the inherent limitation in the texer system that a particle disappears as soon as its center goes off the screen (hence, its dot would be gone). Using texer particles at the edges tends to be ugly.
I *could* fix it by reversing the drawing direction on the right side (so the cutoff is on the opposite side) and extend the image when loading, so that it has a black column on both sides.
Don't have time for that now though. If I update it I'll also add a scaling feature (optional of course) where it scales the dot positions so the particles move completely off-screen before disappearing.
Whilst we are here could we also have different blend modes for the texer? Mainly max blend, i would like to use the texer for creating 'point sprite' type 3d models... but it is impossible at the moment.
jheriko...
effect list (replace/Max)
Texer
you should get the maximum blend effect
effect list (replace/Max)
Texer
you should get the maximum blend effect
I think he means the mode for blending the particles with themselves. I'll see what I can do 😉. Basically it's a lot of copy/pasting of assembly code from colormap.
I have a colormap update sitting here as well by the way, including the requested (R+G+B)/3 index mode, rather than (R+G+B)/2 which is the current 'brightness' (the old mode still works though).
Don't have time to wrap it up and publish it though.
I have a colormap update sitting here as well by the way, including the requested (R+G+B)/3 index mode, rather than (R+G+B)/2 which is the current 'brightness' (the old mode still works though).
Don't have time to wrap it up and publish it though.
nic: yeah i noticed that too.. something to do with the way w and h are made into -1>1.
It seems to be just with the superscope though.
The low limit is always slightly less than -1, and the high limit is always slightly less than 1, so any points at 1 on x or y will never show up.
The actual difference changes based according to resolution and whether or not pixel doubling is on.
Try this: make the window pretty small, and then work out the lowest y value that the scope will work on. (eg. y=-1.00389105; x=2*i-1).
Then make the window nice and big again, and the line should disappear!!)
It seems to be just with the superscope though.
The low limit is always slightly less than -1, and the high limit is always slightly less than 1, so any points at 1 on x or y will never show up.
The actual difference changes based according to resolution and whether or not pixel doubling is on.
Try this: make the window pretty small, and then work out the lowest y value that the scope will work on. (eg. y=-1.00389105; x=2*i-1).
Then make the window nice and big again, and the line should disappear!!)
lalala...😁
I noticed another texer bug:
The track bar wont restore saved settings below the initial one.
Try saving a texer with one particle and reload the preset. 🤪
The track bar wont restore saved settings below the initial one.
Try saving a texer with one particle and reload the preset. 🤪