Welcome to od|forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.

julian johnson

  • Content count

  • Joined

  • Last visited

  • Days Won


Community Reputation

10 Good

About julian johnson

  • Rank

Personal Information

  • Name julian
  • Location london
  1. I've tried to fix your incoming curve. This seems to work.. evenspace_curve_from_edges_maybefixed.hipnc My tree relies on the curve having sequentially numbered points so I merged your 3 primitives into 1 using polypath and then reordered the points using a UV attribute..
  2. pusat's is by far the best way of doing this. But for something rough and ready (and if you're not so bothered by being exactly even spaced) you could try this as well. Increasing the iterations on the for loop increases the 'accuracy'. It's based on even lengths of the original curve so is never going to be absolutely correct. evenspace.hipnc
  3. Exactly. In the example below the position and rotation constraints have different condofs... walkerc.hipnc
  4. I haven't had time to explore the rest but you would imagine that a condof of 0 would allow the object to go anywhere and a condof of 3 would constrain it completely but, hopefully, with this scene you can check that all out.
  5. If you switch the condof to 1 and constrain both rotation and position you're limiting movement to anywhere in the plane whose normal is y (which is why in the .gif below you can see the box only moves along x and z) and you're limiting rotation to any rotation axis that can sit on that plane.. hard_hinge_daryl2.hip
  6. I have no idea if this is any use to you but here's a scene that shows condir in action (with condof set to 2). The first .gif (condir.gif) has both position and rotation constrained whilst the second has just rotation. The constraint axis is Y. In the first gif you can see how movement is only allowed along Y and rotation is only allowed around Y. If you go into the pointwrangle and change the constraint to rotation only you get the second .gif where movement is allowed anywhere but rotation is still only allowed around Y. This scene does not work properly prior to version 16.0.642 as a bug with condir was fixed from that point onwards (i.e rotation about x was the same as rotation about z). hard_hinge_daryl.hip
  7. I was thinking the for loops in both the main tree and the subnet were unnecessary, probably, as the copy function is effectively a for loop by itself. Anyway, take a look at the attached scene - it removes both for loops but this time it does take liberties with your original scene! excercise_11b_ray.hipnc excercise_11c_ray.hipnc
  8. I think there are much simpler ways of doing this but here's one anyway. I've tried to leave your tree as intact as possible. Not sure what you intended for primitives with non-rectangular shapes, though.... excercise_11a_ray.hipnc
  9. I think you need a volume attribute to iterate over i.e. this works (if you bind to density for example): printf("%s\n", "hello", @density);
  10. Thanks Atom. Makes sense..
  11. I noticed a couple of clever tricks in recent sample scenes/tutorials both of which involved calling vex functions with either @P or @primnum in the 'wrong' mode e.g. In Primitive Mode: addpoint(0,@P); In Point Mode: removeprim(0,@primnum,1); In the first case it looks like the primitive calls the average of all the point positions associated with the primitive whilst in the second case the function successfully identifies the primitive connected to the point and deletes it although, I imagine, only because the primitives have been uniqued. I couldn't find any documentation on this behaviour or on what would happen if say, in the second case, the primitives were not unique i.e what primitive number would get returned on a point calling @primnum that had multiple polygons attached? Just wondering if it's safe to 'rely' on these methods or if they're likely to change i.e. might it be just as valid for addpoint(0,@P) to return the position of the first point on the primitive rather than the average?