Homebrew transform jack

yeah, that took me some time to figure out. Anyway, it seems to be working fine with the tangent based rotation angle. Feels natural. Thanks!. I’ll post more soon

One more problem. Lets say I have a null COMP at 0,0.5,0 and a grid at 0,0,0
Now I have a transform handle displayed at the null’s location, which will result in that the y handle is covered by the ground plane.

Is there a way to draw the handle geometry always on top? I tried messing with draw priorities, but they don’t seem to affect this


Well if its not visible then its because it’s occluded by the grid. You’ll need to offset it a little bit towards the camera. Or make it thicker.

Yes it’s occluded by the grid. But I don’t wanna move/offset the handle to another location.

Maybe we misunderstood. Please have a quick look at the file. I want to draw null1 ontop of geo1, so that null1 is always completely visible (regardless off it’s actual coordinates). Much like the xform jack in the geoviewport is always rendered ontop of the grid (even if it’s totally occluded by/located under the grid)
ontop.toe (4.32 KB)

The solution is to use a material (any material) for the transform jack and turn off the Depth Test in the Common page of the material. Then just make sure its drawn after the grid, and it’ll always show up.

it’s working. Thanks Malcolm

New problem. This is my rotate jack. The renderpass TOP controlling which objects are pickable renders: “/geo” and “/HandleManager/HANDLES”. The selected box is located at “/geo/geo1”. The problem is, if I want to use the blue rotation jack and select it at a point where it’s over the box, then the renderpick CHOP almost always thinks I selected the box instead of the blue rotation jack. Gets even worse if I also had a pickable ground plane, then I never would be able to pick any handle.

So to fix this I could, on first select of the right box, remove the right box from the the pickable objects. This could somehow work if all geo objects are directly specified via separate strings in the renderpass TOP ("/geo/geo1 /geo/geo2" ). But as my renderpass only renders/picks “/geo” I see no way to just remove “/geo/geo1” from the pickable objects (while keeping all the other geo objects in “/geo” pickable).

hmm, actually this solution wouldn’t really help, as it would break if I’d also have above mentioned pickable ground plane. Any ideas how to give the handles a “pickpriority” ?


And another problem. If possible, I would like to render this in a way that the lower part of the rotation handle is not occluded by the lower box, but is still occluded by the upper box. Turning off the depth test for the handle will also render it on top of the upper box, which makes the handle very hard to spatialize (not sure about that word)

You could add another RenderPass TOP, have the high priority picks in the first one and the low priority picks in the 2nd one. Use 2 RenderPick CHOPs and if there are no hits in the first one, use the hit from the 2nd one.

A simpler solution would be to just make your jacks a little thicker

We’ll have to add pick-flags to node eventually I bet.
I could also see pick priority being useful, just working it into the UI of every SOP would take some time.

Hmm, you’d need to do two render passes for that. Render the background geometry, then clear the depth buffer and render the foreground geometry.

not sure this will work. Rendering just the handle in the second pass will look the same as turning off depth write for the handle.
If you mean rendering the selected geo plus the handle in a second pass, I would run into the same problem as described in the first question, i.e. if my main renderstring is just “/geo”, how to remove the currently picked object in order to only render the background.

Also, I think this would only work for the upper box in that picture. But if the lower was selected and I’d split it up into 2 passes and clear the zbuffer, the result would look like the lower box sits ontop.

Or did I missunderstood?

Ya I meant draw both the box and the jacks in the 2nd pass.
But ya you’re right, if you picked the lower box they’d both be drawn over the upper box.

So you essentially want the jack and boxes to be depth tested so they look correct, except the jack shouldn’t be depth tested against the box that’s currently picked (but still depth tested against other objects that may be infront of that box).

Not sure if there is a way to do this. If there is it involves multiple passes with creating different depth maps, and then a GLSL shader that does checks with the separate depth maps and decide if the pixel should be discarded or not. You may need a depth map that only has the picked object, and another one that has everything else. Can’t think of a full solution though.

(Ya that doesn’t’ solve the /geo renderingstring issue…)

too bad, when I started this many month ago I thought it was a matter of days :wink:

exactly. It kinda works like this with touch’s jack in the regular viewport. In most situations this is probably not needed, but in some you’ll otherwise only see very minor parts of the handle.

Maybe a “geometric” approach could work. Something like:
Only 1 renderpass
Turn depth test off in the handle’s shader so it’s always on top of everything
Then find a way to delete the parts of the handle’s geometry, which are not visible from the camera, as they are occluded by the box.
Not sure how, but maybe the ray SOP?

Do you see that something like this might work?

Back to the other question

That was my initial setup and it was difficult to manage, as picking a new object would display the handle right away and then that handle would immediately be picked as well (by the same click), but with a couple of frames delay. Together with some value change scripts and panelvariables being triggered without that delay, this caused tons of problems and I couldn’t find a way around. So I changed back to a 1renderpass/pick setup.

hmm, that would require me to use a torus instead of just a line for the handle (more geometry, but probably not so much of an issue).
To bad the wireframe width does not seem to affect the picking.
Besides esthetics (those toruses would need to be pretty thick), this might be way to go until …

every SOP? wouldn’t it be enough to give the renderpick CHOP a string of “preferred” objects?

I wouldn’t worry about the extra cost of a torus vs. a line. The extra cost will be very small, and if you use a constant material it’ll be even less.

Ya I need to make the picking inherit more things from the materials applied to the geometry. Line width, face culling can all affect picking, so they should come from the MAT.

Ya a string of preferred objects would work in this case, but I think it’s just a matter of time before someone has 3 levels of priority they need.

then they could enter 3 objects in that string, and the sequence defines the priority overrides? Just thinking out loud.

Anyway, other topic again

it does (or I’m too tired to see the problem anymore)
handleRender.1.toe (5.74 KB)But there seems to be a weird behavior with the delete SOP. For some reason it closes the circle after deleting the points. Could you please have a quick look?

Also, do you see a way to use the ray SOP information in a carve SOP, so that it more smooth?

Thanks again for all your help

Well, the behavior is correct technically. Its not closing the circle, its just keeping it closed. Lets say you have a line with 3 points, p0, p1 and p2.
Now you delete p1, you aren’t going to get a break in the line, you’ll simply get a line that goes from p0 to p2.
If however you deleted p0, you’d get a line from p1 to p2, and the line would shorten.
So the reason the delete SOP sometimes visually breaks the line and sometimes doesn’t is because sometimes the deleted points are at the ends of the line (this is when it works). When the circle stays closed and looks wrong, its when the deleted points are in the middle of the line. Since the break in the arc is staying at the same point, you’d need to turn this into 2 primitives. Maybe there’s a way to create two lines using a couple of Add SOPs, can’t think of a way offhand, you’d need a way to get the point #s of the points in the rayHitGroup.

Here’s a sample that uses the Carve SOP, its not perfect either but maybe you can build on it. Sorry I can’t do more, gotta head home soon.
handleRender.2.toe (6.11 KB)

ahh, I see. makes sense. Afterall it turns out this approach is to expensive. To get better picking, I’ll have to use a torus instead of a circle, so the amount of points gets much higher. And if I ray three rotation axis with all those new points, the ray SOP takes almost 1 millisecond to cook.

New Idea.
Render the scene without the handle
Object merge just the picked geo and render only it and the handle.
The object merged geo would need a shader which doesn’t actually render the object but still blocks the geo behind it.
Then composite it ontop of the base render and I should get what I want

2 things I’m not sure about:
Can I renderpick an object which is not actually rendered (geo not specified in render TOP, but specified in the renderpass TOP the renderpick uses).

Is it possible to write above mentioned shader in glsl? I was thinking maybe always write alpha = 0 and then, if I don’t turn on alpha blending, it should block the handle.

The Depth Only MAT will do this, render the geo you want to be the blocker first with the Depth Only MAT. It won’t create any colors, but anything that is rendered after it won’t appear if its behind it.

Ya, the renderpick CHOP doesn’t care about anything other than the TOP it’s looking at (and even then, it only cares about the listed objects). What actually happens during the render doesn’t affect the picking, the picking is done seperatly.

it’s working and it’s much faster than the geometric apporach. Thanks for the depth MAT trick!