Rand value in Group Expression

[JH12]

Using a Group Expression SOP I can find the last prim of my geo with @primnum==`nprims(0)`-1

If I want that selection to change randomly between, say the last 4 prims, why does the following not work:   @primnum==`nprims(0)`-rand(@Frame)*4

Also, is the reason I require backticks for the nprims expression above because it is a hscript expression in a VEX context?

Thanks 

Edited August 9, 2018 by Fireandsmoke

[bhouse]

The rand() function must be in backticks as well. Symek does a great job of explaining them here.

Also, rand() generates a random float value between 0 and 1, so when subtracting that from nprims() you will need to fit() your value to the range you want (1 to 4 in this case) and then round the output to the nearest integer. So something like this should do what you want:

@primnum==`nprims(0)-rint(fit01(rand(5),1,4))`

Alternatively, you can do this in a primitivewrangle node using something like:

addattrib(0, "primgroup", "RandomPrim", 0);

float seed = ch("seed");

if(@primnum == @numprim-rint(fit01(rand(seed), 1, 4))){
    setattrib(0, "primgroup", "RandomPrim", @primnum, -1, 1, "set");
}

Example file:

rand_prim_group.hip

[JH12]

Thanks bhouse will give this a try tonight.

Regarding the backticks, symeks post just mentions backticks need to be used when writing expressions in fields which expect hscript.  This is Vex input so does this also apply as a blanket rule in Vex?  

Symek has confused me a bit, he categorises those expressions like npoints () as being different to Hscript, Ive always thought of those expressions as being Hscript expressions.

[Noobini]

simply this ?

@primnum==@numprim-(rint(rand(@Frame)*4))

 

haaaa!!! caught me own bug.....it really should be this

@primnum==@numprim-(rint(rand(@Frame)*3))-1

(if you use *4 version, while you scrub quickly you'd think it's working.....but sometimes NOT....ie...there MUST be at least a -1 to protect overflow)

 

Edited August 9, 2018 by Noobini

[JH12]

Thanks guys.  

So what I am trying to achieve is quite simple in theory but not working for me so far, and I think I can see why...  

I start with a box, which I run into a solver.  Inside the solver I have a very basic setup which takes the previous frame into a Group Expression which randomly selects one of the last four prims, and then a poly extrude to extrude that selected prim.  So the effect should be that the end of the object grows a new extruded face each time, like a twisty branch growing.

Displaying the primitive numbers, I think I can see why this isnt working.  For some reason when the extrude is running through the solver, it shifts the primitive numbers around every iteration. 
Whereas if I were to take a box and extrude it a few times manually, all existing primitive numbers hold their original position, and 4 new numbers are created each time you extrude and create 4 new polys.   

Can anybody explain the logic of why this is happening inside the solver?

Thanks!

polyextrudesolver_project.hiplc

[anim]

as you said nprims() is hscript so if you use it in a snippet using backticks it will evaluate just when the code is compiled on the first frame, so you'll end up with hardcoded value 6 in your case instead of real number pf primitives

so just use @numprim as suggested above

something like this will do

@primnum==@numprim-floor(rand(@Frame)*4)-1

 

Edited August 12, 2018 by anim

[JH12]

anim, thank you! Exactly that. I was watching the geo spreadsheet totally lost as to why the grouping wasn't moving beyond the first frame.  

So if I were to summarise this into a rule for my future self, Hscript expressions, which must be used in backticks to work in a VEX context, will always only return a single value.

If it's not too low level to explain, why is this?  

[anim]

4 hours ago, Fireandsmoke said:

....So if I were to summarise this into a rule for my future self, Hscript expressions, which must be used in backticks to work in a VEX context, will always only return a single value.

If it's not too low level to explain, why is this?  

all hscript or python expressions that are used in VEX snippet are evaluated (therefore expanded into just text) at the first frame, so the only thing you'd use them is to help you produce the VEX code

however since snippet VEX code is compiled only at the first frame, you'll get the values from your hscript/python expressions evaluated only at that frame, you can see how your code looks like when you View Vex Code of the underlying Attribute VOP or in case of group/attrib Expression, there is a Generated Code tab where you can see expanded snippet code