using timeshift SOP with instancepoint

[tomhanks]

I have a FBX file on my scene with animation, so I have a point cloud geometry using it as a instance object.

I want to offset it´s animation per point basis using an point attribute that I created, I tried to use timeshift in the FBX node using a "point" function in conjunction with the "instancepoint()" flag to see if I could get that each instance point could get different frame offsets, but no success, it seems that timeshift doesn't accept custom attributtes or I am doing something wrong.

Resuming, I need a timeshift effect using an attribute value per point basis.

Is there any way to achieve this effect with timeshift? Or another way around?

I hope I could be clear, sorry for the bad english.

Edited March 20, 2010 by tomhanks

[pclaes]

If I understand it correctly, you want to instance geometry and every instance should be offset in time by a certain amount...

You are dealing with the limitation of the instancepoint() expression and the way the instancing works:

        This function takes no arguments. You can use this function in
        parameter expressions on objects being instanced (see point
        instancing). It returns the point number the object is being instanced
        onto. You can use this to vary object-level parameters (such as
        transforms or material overrides) between instances.

        You can not use this function at the surface level, because instancing
        only works at the object level.

Have a look at the example file in the "instance" (object level) help card.

What you will probably have to do is create an object for each timestep (of the cycle) and then use the point sop inside the instance object to assign an instance point attribute, this is a string attribute that has the path to the object that needs to be instanced.

[wigal123]

If I understand it correctly, you want to instance geometry and every instance should be offset in time by a certain amount...

You are dealing with the limitation of the instancepoint() expression and the way the instancing works:

        This function takes no arguments. You can use this function in
        parameter expressions on objects being instanced (see point
        instancing). It returns the point number the object is being instanced
        onto. You can use this to vary object-level parameters (such as
        transforms or material overrides) between instances.

        You can not use this function at the surface level, because instancing
        only works at the object level.

Have a look at the example file in the "instance" (object level) help card.

What you will probably have to do is create an object for each timestep (of the cycle) and then use the point sop inside the instance object to assign an instance point attribute, this is a string attribute that has the path to the object that needs to be instanced.

assuming I understand what you are trying to do. Couldnt you run a foreach keeping only one point at the time , do your time offset based on your desired value and merge the results back together? Might be slow though.... if that doesnt work there is always copy stamping, which shoudl give you similar results (never used instancepoint())

Edited March 20, 2010 by wigal123

[pclaes]

You have to think there is a reason for using the instance in the first place.

Most likely memory consumption. The copy stamping could definitely work, but the copy sop is a memory hog.

Here is a really nice example of how the instancepoint() expression is used with a lightrig at OBJ level (not at SOP level!).

http://forums.odforce.net/index.php?showtopic=6590&st=0&p=44137entry44137

Some of the best ways I find is by instancing a delayed load as you also are not writing the geometry into the ifd.

I am currently writing my own instancer dso in the hdk, based on instancing delayed loads, that is another option, but that will probably consume more time.

[tomhanks]

Thank you very much for the feedback.

I am insisting on the the instance point technique because using it on a renderfarm is very eficient in most cases because you can setup the scene to just load what it needs on render time, of course once is too much it can cause network issues.

I use point instancing a lot, but just with single geometry files so in this case using this technique is great, even using a lot of geometries it works very well, now with animated geometry is another case because it has to load a lot more geometry at once, in a crowd for example it has to load more geometry once if you have to change the animation cycle per point basis, it works but it also causes the network to overload making your render to take a long time to render because it has to assemble the scene first seeking the geometry on the network before render. (Correct me if I am wrong).

My idea is to have just one animated geometry on the scene and use intancing point to populate it just on render time, I can do that except for the change the animation cycle which I am trying to do now, since I can´t use timeshift SOP with instancing point I don't know what to do,

I hope I could make sense.

Any Ideas would be welcome, anyway thanks again fot for the feedback.

[symek]

My idea is to have just one animated geometry on the scene and use intancing point to populate it just on render time, I can do that except for the change the animation cycle which I am trying to do now, since I can´t use timeshift SOP with instancing point I don't know what to do,

I hope I could make sense.

Any Ideas would be welcome, anyway thanks again fot for the feedback.

Save your animation to disk, use delayed load applied on some proxy object and write down an expression based on instancepoint() in delayed load Shop to shift your animation loop.

[pclaes]

Save your animation to disk, use delayed load applied on some proxy object and write down an expression based on instancepoint() in delayed load Shop to shift your animation loop.

hehe... I'm actually doing that in here:

with the exception it's not an animation loop.

[tomhanks]

I did some tests here in the same file.

I have a scene with an fbx file with a character with 2000 frames, the goal is to populate 1000 of them in a grid with alternate cycles, t-shirts textures and also this character has shorts and pants I want to alternate this too, so I have all this set up in two techniques.

The first one is using instancing point, so I have all the geometry animation saved on disk as ".bgeo" files so my main node uses a delayed loader to load all the stuff that the scene needs in render time.

The second I used a copy sop technique where I just have one main geometry which is my fbx file and I have a proxy object setup just to visualize my crowd, the real geometry is cooked in render time.

The first one is very effective on single machine where you have all the files locally and needs to optimize memory, so I've done tests where I have 1000 to 4000 characters on the scene, with 4000 characters my quad core took to render with a resolution of 1280X720 20 minutes, I though that was very "renderable" considering the amount of polygons that it loads, I think I can increase this number even further.

I also tested this technique on a farm, and the same render took more than one hour to complete, the network setup was not at it's best shape but it showed that too many files loading at the same scene can slow renders a lot, because the network overhead, making it not a viable technique.

The second technique in my machine using the copy sop simply crashed my machine, with 6GB ram is not enough to cook all that geometry.

I am still going to test the copy sop on a farm with machines with more than 16 GB ram, I think that will work, but it's just a though.

All this is based in some tests that I've done, I am not in any way a houdini master, I can surely doing something wrong and maybe theres a more efficient way to do that, but I don`t know, that's why I like to hear some thoughts and I thank for the feedback so far.

[pclaes]

Perhaps copy that cycle to each machine on the farm to a temporary folder and load the geometry from a "local" disk on the farm. That way you have the best of both worlds - and for large crowd sims this might be the only way. Consider that if each machine renders 10 frames, you have just saved a huge amount of network traffic. The worst case scenario would be that each machine renders only 1 frame, then your are not gaining anything.

That probably requires some reconfiguration of your paths and I have never done this on a large network either - I have done something similar to this with large fluid simulations because that data was getting quite heavy too.