Jump to content

FlorianEggers

Members
  • Content count

    24
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won

    1

FlorianEggers last won the day on November 21 2018

FlorianEggers had the most liked content!

Community Reputation

5 Neutral

About FlorianEggers

  • Rank
    Peon

Contact Methods

  • Website URL
    https://vimeo.com/florianeggers

Personal Information

  • Name
    Florian Eggers
  • Location
    Europe

Recent Profile Visitors

462 profile views
  1. Executing hda python script every frame

    Right, that would be a possibility too. That push / pull argument is a pretty good one. Thanks Alex!
  2. Executing hda python script every frame

    I actually just found a workaround on the topic below: So `ch("/out/whatever/version")` $F becomes \`ch("/out/whatever/version")\` \$F which now evaluates on the camera's vcomment parm instead of the HDA (and therefore evaluates every frame)
  3. Executing hda python script every frame

    Hi there, I'm in the process of setting up a little viewport comment hda. All it does is changing the vcomment parameter on a selected camera. This works great for static text and variables but I haven't found a clean solution for time-dependent stuff such as $F. Since the hda python module doesn't execute every frame, I'm using a script SOP inside the hda which calls the phm function that updates the text every frame. The problem is, that this results in the HDA function executing last. So when doing flipbooks for instance, the image will be rendered before the hda function executes, thus the text lags behind by one frame ($F will show "1001" on frame 1002). Part of the problem is (I think) that the string is being evaluated inside the HDA. So the actual vcomment parm on the camera will already be "1001" instead of "$F" (which would probably evaluate correctly every frame). So if I could prevent the string from evaluating on the HDA, that would probably solve the issue. I'll try the same thing with a Python SOP instead of on the HDA's python module, but in the meantime, maybe someone has a better solution for this problem.
  4. You can also use the Transform Pieces SOP to do that. Just make sure you have matching name attributes on both the sim and hi-res pieces.
  5. Import Caches into Dopnetwork to sim

    Just to make sure I understand correctly: You import Frame 1 from your cache as your initial geo You sim this wire in DOPs At a certain point, you want to override the simulated motion with the animation from cache One approach I can think of would be to change the geo with a wrangle inside DOPs. Ofc there's a ton of things to think about, maybe if you could post your scene (or a simple example of the setup) I could try what I have in mind
  6. AFAIK there's no way to make this work without scripting. (If there is, I'd be curious to know aswell). As a sloppy workaround, you could expose the "reset Simulation" button of the SOP Solver to your HDA. Using for-loops would solve this issue, I think. You said it's easier to work on the system using a solver, but maybe you could port the logic to for-loops for the final HDA? That would be my approach.
  7. Not sure I understand correctly: You want the Solvers to automatically re-cook to the desired frame (specified in the Timeshift SOP)?
  8. rbd forces question

    In DOPs in your glue constraint relationship, make sure the Data name matches the constraint_name attribute exactly (case sensitive!). In your scene, the glue cluster sets the name to uppercase "Glue", the glue constraint relationship has it's data name set to lowercase "glue". Make sure they both match exactly
  9. stop combine

    Not sure I understand correctly, you want to keep the deformation after the sphere left for the next box? For that to work (e.g. for the boxes to "remember" the deformation), you need to use a SOP solver. More specifically, the vdbcombine needs to happen inside a SOP solver. Alternatively, you could just copy the sphere onto every box. Depends on what you are trying to achieve in the end... Hope that helps, I might have the time to put up a quick sample scene later today.
  10. pyro cache issue

    I never used the "DOP Node" field, but from the help: So my guess is, if you point to your smokeobject in DOPs, it'll work aswell. Sounds usefull if you want to import multiple objects, but I've always used something like "smokeobject*" as the default object. Maybe someone else can elaborate on usecases for the DOP Node?
  11. Split curve input to seperate meshes

    can't test right now, but using the Convert Line SOP might help?
  12. The reason I can think of is consistency. @ptnum of a given point might change if you delete or modify your geometry. If you define something like i@myID = @ptnum; before you do any modification of the geo, and use @myID to generate random numbers, the result will stay the same, no matter if you delete points or change the point order.
  13. rbd forces question

    Set the second wrangle to run over primitives instead of points, then it'll work. Also, in your glue in DOPs, set the strength to 1. It acts as a multiplier to your prim attribute.
  14. pyro cache issue

    in your dop i/o, try to leave "DOP node" empty, but set default object to "smokeobject1" (or whatever the name of your smokeobject inside DOPs is. If this doesn't help, could you post your hip file?
  15. point deforming problem

    Have you played around with the radius of the point deform? Also could you post a scenefile? Would make it easier to debug.
×