Texure Projeciton

[Wan]

hello,

i'm new in Houdini. I've heard Houdini is a great tool for effect shots. I watched video tutorials and I' m impressed with its ability to perforn complicated task.

What's came to my mind: I was wondering if I can setup some bizzare texture map workflow but have no idea how to start. Mayby some of you can halp me or send tips. I'd like to project texture from camera (or light). Texture is animated. And it goes like this:

in $F=1 "my_text.01.pic" is projected from position 1

in $F=2 "my_tex.02.pic" is projected from position 2

(up to now it's simple projection from moving camera... )

but "my_text.01.pic" in frame $F=2 remain projected from position 1

in $F=3 we have my_tex.01.pic from pos1, my_tes.02.pic from pos 2 and my_tes.03.pic from pos 3

so in every frame new texture is added to already projected textures. All positions are in camera path so I need project textures from every position of camera, but textures should "stick" somehow to surface ones projected from proper position.

Please don't tell me, that I have to setup cameras or lights for every frame and project textures one by one... if I have 200 frames it wouldn't be nice.

I sure there is simplier way to achieve it!

thanks,

Wan.

[Mario Marengo]

It would take too long to write an explanation, so here's a hip file showing one approach.

tmp1.hip

Briefly:

1. Projector lights are instanced on each point along the camera path.

2. The camera's in-path positions and orientations are extracted using CHOPS.

3. A string point attribute is added to alter the SHOP parameters for each point.

4. The "slides" being projected in this example are the result of Font COPs showing the frame number. But they don't have to be.

5. The camera path in this example is procedural, but it doesn't need to be.

Please don't tell me, that I have to setup cameras or lights for every frame and project textures one by one... if I have 200 frames it wouldn't be nice.

26857[/snapback]

Sorry, but that's exactly what this does

... except you don't do it manually. This example only took a few minutes to make, so don't worry: 200 point-instanced lights is nothing.

Here's the view from cam1 -- each number is projected from a separate light instance:

HTH.

[Wan]

O my God, that's brilliant! Mario, really thank you very much. Its so frustrating, you know, there is no point one can say that he knows this software, there is always more to know! Endless story!

see ya!

Wan.

[Mario Marengo]

You're very welcome.

And yes, we're all constantly learning new things about this software... can you say "HDK"?

Cheers!

[Wan]

You're very welcome.

And yes, we're all constantly learning new things about this software... can you say "HDK"?

Cheers!

26874[/snapback]

Hope I can

but... one thing bother me, how to switch projection on, light by light, for every frame? I need to add textures frame by frame and not to see them all together from first frame. Should I add point to istance geometry with some variable value? or fix it in shops......?

[Mario Marengo]

but... one thing bother me, how to switch projection on, light by light, for every frame? I need to add textures frame by frame and not to see them all together from first frame. Should I add point to istance geometry with some variable value? or fix it in shops......?

26876[/snapback]

In the SOP "/obj/ProjectorPoints/OnePointPerFrame" (a resample sop), change the expression for Segments, from "$NFRAMES-1" to "$F-1" (no quotes). Now it should only instance up to the current frame only.

I guess you could also put some expression in the light_color parameter of the light shop, but that sounds like it would be messier (and buried).

[Wan]

o great! I had such intuition! thanks!

[edward]

I had fun looking through Mario's file! Learned new stuff myself. The file had some subtleties though so I've taken the liberty of adding comments to most of the operators as well as some minor changes for learning purposes. I hope I understood the file correctly.

lightInstanceProject.hipnc

[symek]

well done, thank you Edward, now it's simple to grab the idea for someone aside. I will try to make animation to show what nice effect can be done with Mario's setup.

[sibarrick]

It would be worth posting to exchange too, it's a really nice example of how utterly cool Houdini can be at doing something seemingly difficult. Probably less than 42 nodes too....

[Mario Marengo]

Wow, Edward! That's wonderful, thanks!

Great annotations and clean-up. The OnePointPerFrame thing is much better that way -- the old method would have left 2 points at frame 1 instead of 1 point (when set to $F-1). I lazily stayed quiet about that, hoping Wan would catch-and-fix... my bad

There are really two possible HDA's here: one for extracting camera animation in the form of a geometric path (+attributes like vel, accel, etc? -- don't see why not), and possibly another to wrap all the somewhat esoteric things needed to instantiate lights with their corresponding SHOPs. The method used in this thread would be a combination of the two.

But... something else I stayed quiet about (and Edward too I believe... heh... partners in crime, lol) is the fact that the camera extraction is not complete (and therefore not generic enough for an HDA). It currently extracts position and orientation, but totally ignores roll (z-rotations). It also depends on two viral SOPs to be added to the target camera... pretty "yuck" actually... just "good enough" for a quick fix, that's it.

Anyway, I'm fairly certain that all these wrinkles can be ironed out... I'll see what I can do, and if anyone alse feels in an HDA-kind'a-mood (and has the time), please go ahead and make it better!

One last thing I'd like to mention, is that I personally learned all of this light-instancing stuff from a wonderful video tutorial that Peter Bowmar put together some time ago. It's very clear and easy to follow. I highly recommend watching it. You can get this tut form VisLab (at the bottom of the H6.0 set -- yes, "Houdini6.0", but it still applies).

Thanks Ed. And thanks PeterB.

[Wan]

These tutorials are great and Houdini is perhaps the only software which old tutorials last valid after many years. I look even into old pdf for 5.5 version because there are so many good points to remember in it. (mayby it's just my poor level of Houdini skils. ?). Personally I see differences only in details. Principles remain the same.

I'm also glad that my small trouble has turned into something valuable for everyone, thanks to Mario&Edward . I will try to show result once I will finish it.

HDA for extracting Camera properties? Sounds good! I'm too stupid to try. Maybe I'll find some new chalenge for better ones?

Wan.

[Wan]

hmmm... this setup doesn't work for keyframe animated camera, I suppose its bacause of CHOP referensing camera channels that should look differnet if we have channels in 'pos' and 'rot' not expression. I try and try but something goes wrong. Please help!

[Mario Marengo]

It should work. I just tried keyframing the camera in my original file and it works fine (and Edward's should too, it's just that it's a .hipnc so I used my old version). Here it is with a keyframed camera:

tmp2.hip

Things to check:

1. That the sops "CameraPosition" and "DisplacedCamViewingDirection" are referencing the correct camera.

2. That the target camera has two sops named "Dir" and "Pos" as in these examples.

3. To check that things are being sourced correctly, point your viewport to anyone of the CHOPs inside "CamExtractor" and you should see something other than flat lines (unless the camera is not moving).

HTH.

[Wan]

that's strange. I recreated your setup and everything was fine untill I have deleted expressions and keyframed camera. camera path geometry disappeared... and I couldn't back to previous scene... sorry for taking your time & thank you Mario, I'll keep try!

Wan.

[edward]

But... something else I stayed quiet about (and Edward too I believe... heh... partners in crime, lol) is the fact that the camera extraction is not complete (and therefore not generic enough for an HDA). It currently extracts position and orientation, but totally ignores roll (z-rotations).

26906[/snapback]

No, I noticed that and discuss it in the comments in the ApplyNormal dude.

[Wan]

ok, I located my problem. My scene starts in 1200 frame.... not in 1 .

I've changed expression in resample sop on this $F-$FSTART-1 but it's not enough... I changed also starting and ending point in CHOPS geometry but still curves in CHOP viewer stay flat as desert. More over Mario's animation is somehow baked in CHOPS, since when I deleted MArio' cam animation and referenced these channels to others one (mine previously animated) camera path geometry remains the same! What a hell is going on here? Some magic.

[Mario Marengo]

No, I noticed that and discuss it in the comments in the ApplyNormal dude.

26932[/snapback]

Hehe... I guess I'm on my own then...

ok, I located my problem. My scene starts in 1200 frame.... not in 1 .

26937[/snapback]

Why would your scene do such a thing?

Are you saying that $F always has values >= 1200? ... and what value does $FSTART have?

I think we've come to a point where you have to post a stripped down version of your hip to be able to help you further. Just the bare minimum that shows the problem you're talking about ... otherwise we're working in the dark.

Having said that, I've played around with a possible implementation of the motion extraction part of the problem. Here's the beginnings of a "PathSOP" OTL which will convert an animated object into a path with the option of adding various point attributes:

path.otl

Haven't tested it very thoroughly, but it seems to be doing the right thing.

@Wan: This HDA has a frame range for the extraction so it may solve your problem.

@Everyone Else: Consider this an initial submission -- I don't consider it finished, and I'm sure there are some problems still lurking in there, as well as features that people will think would be useful to have that are not there. Let me hear what you think.

Here's Edward's hipfile, but now using the shiny new Path SOP

lightInstanceProject2.hipnc

[edward]

Hehe... I guess I'm on my own then...

26940[/snapback]

It was sneaky of you. At first, I couldn't see how the render could have worked.

[Mario Marengo]

Here's an update for the Path SOP:

Changes:

*/ Changed the method used for extracting the local frame. Now it's a lot faster and more accurate (there's a new VOP SOP that handles this, called "Path_BasisExtractor").

*/ Added a "Path_" prefix to the embedded HDAs so as to minimize confusion in the operator table (and tab menu). Though hiding them would be better...

*/ There's a separate control now for the path refinement used to calculate the positional derivatives (vel, accel, and jerk). This helps with accuracy, particularly toward the limits of the path.

*/ Management of the frame range has been beefed up a lot, so now it will behave properly when start- and end-frame values swap sides for example (which can happen when one or both are animating). Super sampling is also a lot better now -- more robust.

*/ Added a whole visualization layer with their respective controls, as some/all of these vector attributes are not very intuitive.

*/ Various other little bug fixes here and there...

This thing is almost usable now!

path_v2.otl

Here's an extracted path with some of the vector attributes turned on for visualization:

Now that I have a reliable local frame, it occurred to me to add an "up" vector to see if the instantiator used it... and wouldn't you know it, it does! (foggy memories of having heard this mentioned before come rushing to my mind). Yup, it works, so mapping 'local_Z' to 'N' and 'local_Y' to 'up' gets you instances that obey position, viewing direction, and roll -- the whole bag. No more weird tricks with the texture maps -- that can be thrown out now. YAY!

Here's the old path but now all lights project the same image. Notice how the images rotate correctly. This is done via the 'up' vector (which is mapped from the Y-axis of the local frame, and is one of the attributes in the path sop).

And Edward's hipfile modified to generate it:

lightInstanceProject3.hipnc

That's it.

Changes, improvements, suggestions, all welcome.