Jump to content
[[Template core/front/profile/profileHeader is throwing an error. This theme may be out of date. Run the support tool in the AdminCP to restore the default theme.]]

Community Reputation

2 Neutral

1 Follower

About Memo

  • Rank

Contact Methods

  • Website URL

Personal Information

  • Name
  • Location
    United Kingdom

Recent Profile Visitors

1,959 profile views
  1. Thanks for the suggestion @bunker. Turns out it's not a permissions issue at all. I've discovered it's because I had separately defined a HOUDINI_PATH environment variable pointing to /opt/hfs18.5 (for my own convenience). So even though I was running source houdini_setup AFTER defining HOUDINI_PATH=/opt/hfs18.5, it was still breaking something. (And the reason why it worked as root, is not because of permission issues, but because HOUDINI_PATH was not defined for root).
  2. Apologies for cross-posting, but this is driving me nuts and I can't believe I cannot find any information regarding this online. I'm getting lots of "ModuleNotFoundError: No module named 'viewerstate'" type errors on Ubuntu. Full details at https://www.sidefx.com/forum/topic/79385/?page=1#post-341733 but TLDR version is: I installed houdini (18.532, on Ubuntu 18.04) and licensed (Indie) exactly following instructions at https://www.sidefx.com/faq/question/install-linux/ and then this doesn't work: cd /opt/hfs18.5 source houdini_setup => The Houdini 18.5.532 environment has been initialized. hscript => gives all of the errors in the linked thread but this does work: sudo /opt/hfs18.5/bin/hscript and so does this: sudo su cd /opt/hfs18.5 source houdini_setup => The Houdini 18.5.532 environment has been initialized. hscript => works Is this normal behaviour? Can I not run houdini without root privileges? If I source houdini_setup in my .profile, then none of that env gets carried on over to my sudo, so I'd need to source it as root.
  3. Hi Netvudu, thanks for the reply. yes reseeding is disabled. Also the artifact doesn't look like a reseeding issue. It's not that I get 'occasional pops'. Instead, very small clumps of particles are not being interpolated. instead they are moving every 4 frames (you can see this in the videos - or directly in the hip). I can't figure out what it is about those clumps of particles that make them not interpolate. I've had a look at the geometry spreadsheet (or whatever it's called these days), and I can see my particles have a class attribute, and have values of 1 and 2. I've tried isolating class 1 and class 2, and both classes exhibit the same behaviour (i.e. tiny clumps in both classes of particles don't interpolate). I don't know how else to debug the problem.
  4. I have a flip + whitewater sim which I've cached with all properties, now I'm slowing it down 4x (i.e. timewarp frames 1...6000 stretched to 1...24000) and I'm using timeblend (i.e. cache -> timeblend -> timewarp -> NULL_OUT) Most of it is working, but for some reason there are some artifacts, some (very few) particles are not being interpolated. You can see what I mean in these videos (I'm rendering as seq of tiff with alpha and I've tried 3 diff alpha matting methods -ignore, straight, premult - and it's noticable on all). https://www.dropbox.com/sh/wo2fm2qjd87vhbw/AACkLgoOCqFzehwz8pLyLEfGa?dl=0 (especially obvious when watched frame by frame). in the link above I've also included a tiny segment of my raw data and a minimal hip file which shows how I'm doing the timewarp+timeblend I have no idea what this is, or even how to debug it. Any ideas welcome!
  5. Is whitewater broken in H14.0.444

    Thanks Marty, I didn't know about those journals, I'll keep an eye out for them! Unfortunately none of those mentioned issues seem relevant. I.e.I tried enabling the Jitter Birth Time and increasing Velocity offset as mentioned, but it didn't address my issues.In fact I could hardly tell the difference. for those that are curious, here are the two sims overlaid, the dark particles are my original cache from a year ago, the bright particles are a new whitewater sim, with the same hip file but opened in H14, and using the same flip cache as I used to generate the whitewater a years ago. You can see they're dramatically different https://www.dropbox.com/s/ls2ne63xpi6ihc3/H14_whitewater_problem.mp4?dl=0 note that there seem to be more random noise on the new sim. I don't know if that's new, or just magnified to avoid the dreadful dropbox video compression you may need to download the video.
  6. Hi All, I just opened up a hip I had made with H13 a few years ago which involves a simple flip sim with whitewater, you can see a render here https://www.dropbox.com/s/7dofebetwftrwia/waves_foam_2_cam1_halfspeed_60fps_40Mbps.mp4?dl=0 (this is just the whitewater foam) I have the cache of the raw flip output by itself, and I'm using that to feed into the whitewater sim. When I generate the whitewater, the results are very different to what I had before (I still have the cache of the original whitewater too so I can compare). What I'm observing is that no whitewater particles are going into the body of the fluid, instead they are just disappearing instantly and staying around the edges of the fluid. There seem to be other weird artefacts that I can't put my finger on (bits of whitewater particles appearing and disappearing instantly) I've tried some of the shelf tools for waves etc but I have no comparison since I don't have H13 installed anymore. But the shelf wave tank also looks like the whitewater is mainly around the edges and surface and doesn't sink into the fluid with forces. I am downloading H13 again to compare, but I was wondering if this is a known issue, or if a setting has changed that I can't find or have forgotten about!? I'm on Indie edition btw.
  7. Probably very simple, but I can't figure out how to control the local coordinate system for polyextrude. I.e. point control over in what direction to extrude the points. I'm setting the point normal, but it has no effect. If I use a particle system, connect those with add, and polyextrude, the extruded faces are completely static; however if I use the Trail SOP, the direction of the polyextrude is changing every frame. How can I control it? Simple HIP attached. trail_polyextrude.00015.hipnc
  8. Super fast rendering

    wow that's perfect thanks!!
  9. Is there a way to get a super fast render out of Houdini?, Kind of like a flipbook, but I'd like to queue them etc Basically I have a number of shots setup in my scene, cameras, takes, bundles etc. I've got a bunch of scripts and ROP nodes setup to render them all, but first I'd like to get a super draft version output so I can do a preliminary edit, make sure all my in/out points are ok, cameras are good etc. I don't want any shadows, lighting, AO etc. I've played with everything mentioned on here, removed reflections, refractings, shadows etc, (couldn't find how to get rid of AO, I think it's embedded in the algorithm), brought samping down to 1, turned off the ray variance, tried raytracing vs PBR vs micropoly. I removed everything I could and exported 640x360, until basically all I was getting was almost a bunch of colored noise that resembled my scene. but still I can't get my rendering under 3-4 seconds per frame, and with thousands of frames to output, that's still hours to wait. I've also tried different files and encoding / compression (or lack of) to see if that's the bottleneck. But even uncompressed tiff (about 300KB per frame writing to an SSD) was at 3-4 seconds per frame. All of my geometry is cached, when I press to do a flipbook it speeds through them at realtime speed so it's nothing in my scene either. In fact the quality in the opengl rendered is far good enough for my needs, but I have 36 shots and to keep exporting flipbooks manually and individually is a major pain in the arse and unmanageable. So my two questions are: 1. Is there a superfast old school renderer that can just churn out draft renders for previz purposes? 2. failing that, is there a way to queue and manage flipbook generation, ideally somehow linked to all of my mantra nodes (to know what cameras, frame ranges, objects, bundles, takes etc to use)
  10. Programmatically modifying a color ramp

    why shiver me timbers that worked! thanks. Can I ask how and where you found this info? I searched all the docs but couldn't find anywhere that you could do this.
  11. Is it possible to programmatically modify a color ramp via python (add / remove / edit keys,values, basis etc)? All I've found is this http://www.sidefx.com/docs/houdini13.0/hom/hou/Ramp which only explains how to read these values, not write to them. The reason I'd like to do this is: I have VEX code which colors my particles based on a number of color ramps. That all works fine. However editing the color ramps can be cumbersome, and I already have color palettes created in photoshop which I'd like to use. I thought my options are: 1. Hand edit the color ramps to reflect the color palettes. Very boring and tedious. 2. Hand enter the RGB values into VEX. Even more boring and retarded. 3. Write a tool which loads the palettes in whatever format, and modifies a color ramp to reflect the palette. The VEX code just references this color ramp. This code would only execute once obviously, I load my palette and bang, the color ramp is up to date. I loved this idea, because I could scatter a bunch of these nodes around, each one a different palette, and the VEX code just references a different node for a different palette. However I can't find how to modify the color ramp so I'm stuck. My plan B is to output the RGB values to number box arrays, and have VEX reference that, which might be faster anyway, but I lose the in between values and the ability to visually tweak the palette in context. Any ideas?
  12. creating white water on cached fluid

    It does work fine from cached bgeos, you'll need to feed it: - flip particles - surface volume - velocity field [3] volume So if you cache the raw output from the fluid sim it should work (i.e. do a Dopimport fields, and add your surface and velocity fields to it as well. this is the default setup if you use the shelf tools). If you feed it just the points it wont' work. P.S. you can cache the raw output from the fluid sim as mentioned above (immediately after the dopimport with the surf+vel fields) or what I've been doing is separating the surface volume and velocity volume and points, caching each of them to separate files / folders. In fact reducing the particle count to about 10-20% and then caching them. So I don't get 1GB per frame files but much more manageable. Of course you lose resolution on your particles if you wanted to render them, but I don't so I don't care, and I'm low on space . For the white water sim if you just merge the three streams with a standard merge tool and feed that, it still works fine. Example hip attached. fluid_tests.00004.hipnc
  13. Hey thanks for the reply. That's an interesting idea. You're basically saying use existing geometry and just deform it. It sounds like it should work. My source is quite dynamic, and there are thousands of src points, so it's going to be building up a lot, I'm not sure how it will affect performance if I'm also dynamically creating thousands of grids and deforming them. I'll give it a shot on a small scale to see if I can even do it.
  14. I have a group of points - a cached particle system - and from each point I want to emit two particles, and then triangulate these two trails together like a ribbon. One edge of the ribbon is from ParticleSystemA, the other is ParticleSystemB. (The two particles emitted from each point, I actually have as two separate particle systems, and I'd rather keep it that way if possible. More on this below). So SRC feeds ParticleSystemA and ParticleSystemB, which both have the exact same emission properties and life and everything, so they are always in sync, there is always a point in ParticleSystemA which corresponds to ParticleSystemB, in fact they even share an 'id' attribute, only difference is their behaviour and where they go. I've tried many things, but the closest I've got is: - 'Add' after each particle system, add polygon by attribute 'src_id' (I copy each src particles id into src_id before the particle system, so each trail knows who it belongs to). This connects each of the particle trails into a line. Which is good. - merge the two streams, and add a final add polygon by attribute 'id'. Going into the two particle systems, each src particle has a unique ID. Now when the two streams are merged, there are two particles for each id, which correspond to each other. I want those to be connected. This 'add' SOP does that, and connects them with an edge. But I cannot for the life of me figure out how to make that into a poly! It feels like I need one node to complete this into a surface but I can't find it! I effectively want to create a triangle strip trail per original src particle, which goes: src_point, a[0], b[0], a[1], b[1], a[2], b[2], a[3], b[3] etc. but I cannot figure out how to do it. I've attached a simplified hip file. P.S. The reason why I don't want to mix the two different particle systems into one system is because I have created them as separate tools and they are already cached separately. I can merge them if that is the only way, but I'd like to think it is possible to merge the two streams and triangulate. particle to particle trail test stripped.00020.hipnc
  15. Just wondering if you got anywhere with this? Is it possible to hack / mod houdini for it to work properly? I've got my houdini setup with Sublime Text (and this great VEX package for it) but currently the only way I've found it works is: - select your code field in houdini (e.g. wrangle snippet) - press alt-e to open the code window - click on the 'external editor' button on the code window - edit in sublime - close the window and save on exit - click apply in the code window, and only then does it apply. Obviously this is ridiculously unusable. It's easier to just copy paste from sublime into the snippet field! (Which is what i'm currently doing). Surely it can't be too difficult to hack this in to work properly?