Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won


m-egger last won the day on July 4

m-egger had the most liked content!

Community Reputation

26 Excellent

About m-egger

  • Rank

Personal Information

  • Name
    Martin Egger
  • Location
    Ludwigsburg, Baden-Württemberg
  1. Simple Tree Tools

    By the way, just found this interesting tip on the Think-Procedural Discord: This option displays curves with @width without the need to create geo! Might be helpful instead of creating the preview-lines the way you do.
  2. Mother Nature's Power

    Another Tool that I build some time ago was a particle to debris tool. Just something to save myself from doing for the one-thousandth time. It automatically creates debris pieces from a simple box shatter and instances those particles onto incoming particles. It detects whether pscale/id is present and does all the stuff you would normally do for each debris sim. It also normalizes the volume for the debris particles (with some fancy math) so the distribution of scale can be handled cleanly through the pscale on the particles.
  3. Simple Tree Tools

    True, a video really helps. But the provided example file already demonstrates exactly how to use it, it just doesn't advertise it, unfortunately. Nice, looking forward to the update!!! :))
  4. Mother Nature's Power

    This is a universal fracture-solution that I built to give me interesting results in a more light-weight way than the material fracture. It essentially gives really natural chipping and piece detail. I developed it for the coal plant falling. Unfortunately, it sometimes lead to pieces having zero volume, causing major issues in Bullet sims, but a simple analysis and fix solves that too. @Noobini, this was the culprit. And this is the origins and the core, a looped voronoi with variable densities and iteration count. It yields really good results for structural geometry like buildings. And also a subfracture tool that I built which analyzes the pieces and fractures the ones above the average (+-percentage). Red is the selection, white are pieces eligible from size, but randomly deselected and dark grey is the pieces that are too small.
  5. Animate RBD in 2020 (Strict Follow Input-Position)

    Yes indeed. But at least analyzing the pre-built Guided Simulation gave me a clue on how to do it properly for myself. I think I'll go the route of soft constraints on the guiding geometry that's now animated. Like invisible tentacles that pull the structure down. Seems the most controllable/natural after first tests. And just to document another interesting thing with the pre-built guide feature on the Bullet SOP-Solver here: The guiding only works input geometry with primitives. I wrongly assumed it could handle it sort of like a point deform, but it just pulls the pieces apart towards the points in a weird way.
  6. Bullet Pieces stuck in air as inactive (SOP-Solver)

    Yes!! This is the point, thank you! I must have searched really poorly to not have found anything on this before - at least it's documented in one more way now. The pre-fractured geo was indeed sliced up by "funny buggers" a custom fracturing process with multiple voronois over the same geometry (I love the fracturing result though), and it apparently caused certain pieces to have no volume at all. All this also translated through the simplification-setup which placed spheres with the same volume as the fractured piece at the centroid. *Facepalm* I wish I could buy you a beer! Thank you so much.
  7. Hello, I'm currently struggling really bad with completely unpredictable behaviour of the Bullet Solver and am completely out of ideas with how to debug it further. I'm having a large structure fall into a sinkhole and my current test was just about letting the whole thing drop to the bottom. Now what happens is that certain pieces just get stuck in the air and it seems that no amount of attribut cleaning can fix this. I've had this happen earlier in this project, but also faced it on previous ones very arbitrarily. Currently it's stopping any progress, however, hence this cry for help. This is one of the cache-dailies, without constraints, that demonstrates the issue best: This is a screenshot: (((Ignore the ground, it's a seperate sim and just serves as a backdrop here, not affecting the sim, the whole structure SHOULD just drop straight down))) If I glue the pieces together, the thing just sticks in the air and only the bottom rows fall: I cleared all attributes on the input geo, on the constraints, rebuilt the constraints from scratch, all the same. Has anyone else come across this? I tried on 18.0.460 and the latest 18.0.499, completely clueless. Could this be a bug? It seems so arbitrary. This is the setup in it's simplest form: Same thing happens, the whole thing just gets stuck in the air as soon as the pieces are connected by the constraints. The constraints are setup with the default configurations of the RBD tools, the attributes on those are nothing out of the ordinary. I can't seem to be unable to upload anything but screens here, so I put it here: https://gofile.io/d/g6XdaY Thanks for any help, Martin
  8. Simple Tree Tools

    Man, I can't believe how unnoticed this has stayed. This is an amazing toolset. It's so powerful, polished and nice to use! I unfortunately don't have a use for it at the moment, but I will definitely keep it on my shortlist as soon as any sort of foliage task comes up. Thank you for developing and sharing this! (Edit: I might think it's very hard to find due to the concatenated name. When I searched for this again after discovering it in the past, "Simple Tree Tools" would not turn this up at all unfortunately. Learn something new about Search Engine Optimization every day, haha...)
  9. Animate RBD in 2020 (Strict Follow Input-Position)

    Thanks noobini, still looking good!!! I will take a look at it first thing in the morning. But to document/answer my own question from before: I also just found out that it is viable to set the RBD attribute "animated" to 1, however, it will only the effective when "active" is 0. Just that now again, the constraints behave quite uninterested in the animation, haha.
  10. Hey, since I didn't find anything on the matter that's less than 7 years old (And not even the mighy tokeru-cg-wiki having a post about it) I thought I'd ask for some updated insights. (I'm currently struggling getting a huge coal plant to fall into a sink hole. Now the ground I just did seperately as a guiding sim and now I want the coal plant to follow this ground in the fall down.) What I'm trying to do is get the pre-ran RBD sim as collision objects or static colliders and attach the coal plant RBD pieces with constraints to those falling guide pieces. Is there any way to do that? I was just looking around the forums (here and sideFX) and I found really little about the topic. Doing some RnD I got frustrated quite quickly because after all possible combinations of "animated" & "deforming" attributes set and collision object yes/no and constraints that I could think of for a couple of hours, the best result that came out was this: The test scene is attached. rbd_animate.hipnc And that seems like I'm really not getting behind some science there. Here, I'm updating the position inside the Bullet-Solver-SOP with a POP-Wrangle to the input, but the constraints get screwed up too. Since I'm trying to stick with the Bullet-Solver-SOP (for a couple of reasons), I'm also having a hard time getting a custom constraint SOP-solver into the mix to update the constraints seperately. I'm sure there must be a cleaner way (with the animated attribute) though. Any leads? The documentation is really sparse on this end. Thanks, Martin
  11. Hello! I thought I'd create a thread to document some setups on our diploma project here. We're studying Animation at Filmakademie Baden-Württemberg and we'll graduate March/April 21 and are working on a concept for a social spot promoting green energy with serious VFX. We're currently 15 artists on it, but a lot of them are only on it beside their job, so it's way less actual manpower, but over the long production time we're still looking at some good potential. And with a bid of 500 man days, we've got our hands full. Here's the initial concepts for our three key scenes: 1) An oil rig being crashed by an iceberg, 2) a coal power plant collapsing into a sinkhole, and 3) a giant volcano erupting and transforming the landscape into one of natural sources of energy. We've built a few pipeline tools to make our work easier, here is a couple of the one's I'm really happy with: This one features a lot of python and optimizations for really cool features like progression tracking as comment. (It is a bit crashy sometimes due to Houdini+Windows issues and support couldn't help me, hopefully it gets fixed someday.) All credits to my colleague Lucas Bruchhage and Dominik Lingenover (DMNK) for setting this lifesaver up. Once we are done I am very happy to share the tools. Cheers, Martin
  12. Woohoo! Managed to fix this by accident. And finally figured out how the python server works - kind of. This is the setup and it fixes the issue completely. The gen_range detects the duration of the ticker from the settings on the HDA and the wait does a simple time.sleep() while the update_comment then does the fancy updating I want. Pretty much the same code as before with a few tweaks. I'll rename the topic so that it might be found by others having similar issues! Cheers, Martin
  13. Heyya, I'm currently developing our project-internal filecache node with a couple of fancy features for usability / productivity. The current workflow is starting a seperate Houdini instance with Juraj Tomori's Tool here: Background Render Now I also wrote a couple of scripts that update the progress of the currently ongoing cache by analyzing the output directory and showing the progress. (as well as some info on the output like time per frame and size). [This was primarily developed for the use within a TOPs-Render network, however, the background process variant turned out to be much superior for a variety of reasons.] Now what I built was a script in a seperate TOP-Network which is supposed to execute this analysis every couple of seconds for a given amount of time using the time.sleep(t) function. Now usually this does exactly what I want, keeping this process/sleeping in the BG and execute the analysis function while Houdini stays functional. However, the problem is that sometimes (quite unpredictably, but mostly when aborting/refreshing this TOP-network) this sleeping switches to the foreground, causing Houdini to freeze for however long the ticker was set. And this is game-breaking when you sometimes have to wait for five minutes. You get the point. Here is the (admittedly clumsy) bulk of code: import time import hou import os PARENT = hou.node("../../..") ticker_s = PARENT.parmTuple("ticker_s").eval() break_at_end = 0 node = hou.node("../../../mnp_cacher") fstart = node.parm("f1").eval() fend = node.parm("f2").eval() totalframes = int(fend - fstart) dir = PARENT.parm("outputfile").eval() dir = os.path.dirname(dir) def outputchecker(dur=20, tick=1, confirm=1): iterations = dur / tick warning_message = "Starting updateticker for {} seconds.".format(dur) if hou.ui.displayConfirmation( warning_message ): i=0 while i < iterations: i += 1 #print "Iteration: " + str(i) #SCAN OUTDIR LOCAL CODE ---------------------------- counter = 0; duration_list = [0] folder_size = 0 for (path, dirs, files) in os.walk(dir): for file in files: if ".hip" in file: #exception for backup #print str(counter) + ": SKIPPING" continue filename = os.path.join(path, file) folder_size += os.path.getsize(filename) # --- GET FOLDER SIZE mytime = os.path.getmtime(filename) # --- GET CACHE TIME counter += 1 if counter==1: counter #print str(counter) + ": EXCEPT" else: prevtime = os.path.getmtime(filename_prev) myduration = mytime - prevtime #print str(counter) + " - " + str(mydur) if myduration > 0: duration_list.append(myduration) filename_prev = filename #------------------------------------------------------------- scan end frame = fstart + (counter-1) allframes = fend-fstart curframes = frame-fstart progress = curframes/allframes percent = "{:.0%}".format(progress) # ----- SCAN OUTDIR AND UPDATE COMMENT scan = PARENT.hdaModule().scan_outdir(dir, 1) #print message running_message = "" running_message = "CACHING: {} (Fr.: {} / {})\n".format(percent, int(frame), int(fend)) running_message += scan running_message += " [Update Ticker: {} / {}]\n".format(i, iterations) PARENT.setComment(running_message) time.sleep(tick) outputchecker(ticker_s[0], ticker_s[1]) This looks something like this if executed properly, and I've fallen in love with the info I get from this: Now what I don't get is why this sleeping switches to the FG-process of Houdini. The python-script-TOP is set to evaluate In-Process, but when executing cleanly, it works in the BG nicely. I'm grateful for any clue or alternative approach. Thanks, Martin
  14. vex precision problem

    https://jurajtomori.wordpress.com/2018/11/24/precision-in-houdini/ In case you didn't run across this already with google, this is a super interesting read by a colleague of mine, @Juraj. He did a lot of testing in this area for his diploma project while working with fractals.
  15. Hey, in order to make work on our diploma project easier, me and a colleague developed a slightly advanced filecache simplifying the process of iteration for us and junior artists. Now to make reviewing easier, I want to simultaniously output an OpenGL-render for every frame after the geo is done. In ROPs this is super easy and my standard setup whenever I am developing some FX. This is the general layout: Since for this filecache I am relying on TOPs to make outputting quicker and more streamlined, I am now facing the issue that I can't get the ROP-Fetch to replicate what normal ROPs would do. I deliberately don't just put a ropgeo-TOP and a ropfetch with just the daily after each other because that has to start a seperate Houdini instance just for the OGL-render, which is extremely inefficient, as the render itself takes just one or two seconds - and I don't want to increase the batch size either, since that would cause a delay in the OGL-output after the sim is done. I just want it to output it right after each frame is cached. With two ROPs after each other, this works wonderfully in my experience. In either of the following two layouts the ROPnet would do what I want, which is output one frame of the GEO-ROP and one frame of the OGL-ROP one after the other: Unfortunately, now what happens with the ROP-Fetch in TOPs in the exact same layout is that apparently the very first work item already renders out the entire sequence. In the two days of debugging that I've invested so far I've tried loads of things that came to my mind, one being just using the pre-built ropgeo-TOP-node and inputting my daily-ROP there. However, there, even weirder behaviour happens. If aligned like above, it simply ignores the OGL-ROP and if I ROP-Fetch just the OGL, the very first work item outputs the full frame range and all other work items are ignored. Either I missed some hidden settings in the thousand times that I went over it or this stuff is a bit buggy. I'm hoping for the former. Cheers, Martin EDIT: Alright, after chatting with support, it turns out that the python updating the comment of the parent node was causing the crash. Well, have to go without this nice UI thing then...