just sort.
not parent.
I noticed that I need to add this in order to not have soft gradients across polygons
polyop.applyuvwmap obj #face channel:99
this “explodes” the mapping so that every map face has it’s own unique set of mapping verts that are not shared with any other face.Shared verts will blend unshared will give hard lines (unless neighbours have the same colour.)
btw
fn fnSortValues a b = if (a.dist < b.dist) then -1 else if (a.dist > b.dist) then 1 else 0
can be reduced to
fn fnSortValues a b = a - b;
no idea why the help has the long winded version :hmm:
a quick sketch to show the differences between geo verts/geo faces and map verts/map faces. There is a 1 to 1 correlation between geo faces and map faces but not between geo verts and map verts. Mapping verts can be in any combination between the planar map and the face map. (please note vert order may not be as in max ) So in the face map variation a face can have unique colour that is not shared with the other faces and will give a hard edge. (sorry just notice 9, 10 should be 8, 9 :argh: )
it’s true only for integers and floats where distance between values always more than 1.
try to sort values from -1.0 to 1.0 and you will see the problem.
sorry yes you are right, i was looking at some image sorting code for my atlasing script where the short version is always valid
just seen this variation in some old code
fn compfn x y = (x - y) * 1.0E7;
i’ve played with the idea to use subtract instead of greater/less and couldn’t find any noticeable difference. check this out:
fn comp1 x y = if (x < y) then -1 else if (x > y) then 1 else 0
fn comp2 x y = (x - y) * 1.0E7
(
seed 0
ar1 = for k=1 to 100000 collect (random -1.0 1.0)
gc()
t1 = timestamp()
m1 = heapfree
qsort ar1 comp1
format ">> t:% m:%
" (timestamp() - t1) (m1 - heapfree)
format " %
" (gethashvalue ar1 0)
seed 0
ar2 = for k=1 to 100000 collect (random -1.0 1.0)
gc()
t1 = timestamp()
m1 = heapfree
qsort ar2 comp2
format ">> t:% m:%
" (timestamp() - t1) (m1 - heapfree)
format " %
" (gethashvalue ar2 0)
)
Wow, great explanations of the different mapping types. I appreciate that. It helped clear up a few things I was wondering.
I’m trying to make it so users can adjust the color/groups after they are initially made, I just need to make a function which explodes all the polys from the start and if the geo changes then redo it.
strange code there Denis as its written on my machine the comp2 is marginally slower and uses approx 4 times the mem, if you swap the order comp2 is the faster and only uses 2 times the mem . IIRC the subtraction function was written in response to the help files case variation.
i’ve noticed this too. i have no idea why the order changes the result. probably max does do gc in other than mxs thread. so it causes some delay of updating memory data, and code execution.
OK. i got it. that gives the stable result for any order:
fn comp1 x y = if (x < y) then -1 else if (x > y) then 1 else 0
fn comp2 x y = (x - y) * 1.0E7
(
seed 0
ar1 = for k=1 to 100000 collect (random -1.0 1.0)
gc()
t1 = timestamp()
m1 = heapfree
qsort ar1 comp1
format ">> t:% m:%
" (timestamp() - t1) (m1 - heapfree)
format " %
" (gethashvalue ar1 0)
)
(
seed 0
ar2 = for k=1 to 100000 collect (random -1.0 1.0)
gc()
t1 = timestamp()
m1 = heapfree
qsort ar2 comp2
format ">> t:% m:%
" (timestamp() - t1) (m1 - heapfree)
format " %
" (gethashvalue ar2 0)
)
on my machine comp2 a little faster but takes about two time more memory.
whats with this thread, i can’t get onto the 3rd page ? :hmm:
working now :curious:
btw when i posted that subtraction method I had a feeling you would need to profile it’s performance.
try it with this, the version in the help…
fn comp3 v1 v2 =
(
local d = v1-v2;
case of
(
(d < 0.): -1
(d > 0.): 1
default: 0
)
)
comp3 gives worse performance. it’s >1.5 slower than other two. the memory usage is the same as with comp1.
more max weirdness
fn comp2 x y = 1.0E7 * (x - y);
is marginally faster than the original.
added this
int comp(float x, float y) { return ASM_Round(1e07f * (x - y)); }
to my fnlib for a bit of fun, 33-34% faster than comp1 but still has the same x2 mem usage issue though (the ASM_Round saves a mooosive 1% over an int cast )