Welcome to od|forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.

LaidlawFX

Members
  • Content count

    765
  • Joined

  • Last visited

  • Days Won

    16

Community Reputation

112 Excellent

1 Follower

About LaidlawFX

  • Rank
    Houdini Master
  • Birthday 02/23/1985

Contact Methods

  • Website URL http://LaidlawFX.com

Personal Information

  • Name Ben
  • Location Kirkland, WA
  • Interests Getting away from the computer
  1. Welcome to the forums. The issue is that you are ray projecting a 3-D noise-field onto a 2-D surface. Imagine looking down on a 3-D box of trails that run through curl noise and even though it does not bunch in 3-D space as you spin around it. If you look at it through orthogonal views you will see it appears to bunch. I attached your scene with the fluid source sop showing what I mean. If you increase the length of your trail sop you will see the shape of the noise field. I increased it to 500. You can animate the noise the field if you want, but it's more of tackling the symptom that alleviating the issue. But it may get the job done that you want. curlnoise_trails.hipnc
  2. I'm writing out the full steps to issue, as it makes the issue transparent. The $FD/$FFD doesn't seem like the right solution in this case, the issue seems to be more in the file dialog when you fully parse through it. ----------------------------------------------------------------------- If you have written out incremental frames via the file rop i.e. Start/End/Inc (1,4,.25) http://www.sidefx.com/docs/houdini/nodes/out/geometry with $FF as so: $HIP/geo/$HIPNAME.$FF.bgeo.sc In the "Choose Geometry/File" browser for instance it will look like this. When you toggle Show sequences as one entry, instead of seeing a single entry you will see one for each decimal allocation, and for the . This appears contrary to a single FileWrite.$FF.bgeo.sc sequence. If you are using the file browser to select one of these sequences, it will pick it like this: $HIP/geo/FileWrite.3.$F.bgeo.sc, or the main one like this: $HIP/geo/FileWrite.$F.bgeo.sc By changing the frame to read in increment and by varying the shape with something like color per each subframe, fit($FF,ch("../rop_geometry1/f1"),ch("../rop_geometry1/f2"),0,1) you can easily see the substeps prior to the file read. If you use the file sop to read and you pick $HIP/geo/$HIPNAME.$F.bgeo.sc it will change the interpolation at each solid frame at .5 so you don't have gaps. With $HIP/geo/$HIPNAME.$FF.bgeo.sc it will read the frame interpolations at 1, 1.25, 1.5, 1.75, etc... and will not interpolate the frames. So you need the file browser to have the option of showing not only $F but $FF which is Skybar's issue. The example of file.$SEQ.$SHOT.$F.bgeo.sc is the alternate method you are trying to avoid if we tried to modify $F, or $FF to handle this through out the package we run into more problems. Additionally, the file browser however will not show $SEQ, or $SHOT in it just like $FF, as it only knows $F. So the inherent issue being the display in the file browser is showing those multiple files, and not showing an option for $FF after the first relevant one, and they make you feel like you need to select them to access the subframes. With shotgun or custom file readers and writers you generally don't look at this browser. So really just modifying the display of options in the file browser could suffice to solve this problem. One simple solution is to include in the browser not only $F when you toggle on Show Sequences As One Entry, but also $FF right under it. Another solution is to have a second toggle box next to Show Sequences As One Entry, that says Hide Decimal view where it does a detection on $F from a viable $F.$F. that is #.#. prior to the .ext if there are multiple #.#.#. as that is the default inside Houdini i.e. $HIPNAME.$OS.$F.bgeo.sc where the $F is prior to the extension. Alternatively you could put a Hide Decimal in the Houdini Preferences, maybe General User Interface??? idk what location is better. Additionally the help for $FF in http://www.sidefx.com/docs/houdini/render/expressions or http://www.sidefx.com/docs/houdini/ref/windows/file could explain this incongruity with how the file dialog is selected. Hopefully that fluffs it out further.
  3. You could do a new variable, like $FD, $FFD Frame decimal or something with a better name. This would solve both issues.
  4. If there is a legal issue to replicating the fbx data, I could see that as an issue, however, that should have been stated way earlier if that was the case. Eitherway there are a few ways to package the same data, with out using the exact same source code, with a different dcc. The HIK logic to create the data is not exactly hard, how they pack it into the fbx might be a bit different.
  5. Your lack of imagination is amazing... How do you know if the current system can handle the baking of information when exporting from Houdini? Say I want to pass it back into motion builder to do further work on it, and then render it in Unreal, Unity, or perhaps a proprietary render engine. Just like every other animation pipeline out there does. Or better yet I have a custom Studio pipeline that needs to process or handle the data, prior to exporting it out to a custom formatting for their own unique compression algorithm. I see why Houdini will never be the animation package of choice.
  6. First off welcome to the forums, and the best of luck on seeing your project through. I'll break my answers line by line. So with this information in mind, you are going to have a few key ingredients in your scene; Volumetrics (Pyro), Geometry (Stones), Volumetric Lighting/Lighting, plus the orb(combo). For each one of these the elements they'll be further broken down into their parts/elements/components i.e. the constituent parts of the orb. Beyond just making the components each one represents what you are passing off to Nuke and how you will be breaking it apart in Houdini to light and render. I would recommend making a storyboard of the sequences, or a sketch of the shot and listing out exactly what each element is made and composed of afterwards. Not magic or iron per say as they are description, but the orb has a lighting bolt inside it, the shell of the orb is more like a bubble than glass ets, it radiates outwards, it is deforming, etc.. Then you can break out the "how" each are created in Houdini i.e. the rocks are a hand model shape because it was a statue, as opposed to noised based sphere, and they are voronoi fractured and hand animated, and they will be geometry done in sops. The "how" you will do each element you can fill in over time as you research and learn, but identifying the elements so you know how to process them will allow you to get more direct solutions especially for Lighting and Rendering. There are several paths to process everything, especially if you are going to post process it in Nuke. Preferably you would have your lighting source and your geometry in the same scene. You will either use multiple render output driver, i.e. mantra nodes in out for each main element with render passes (extra image planes) for each aspect of lighting. Or you can you render it all in one beauty pass and use a ton of render passes. Additionally you can use Deep Compositing in Nuke and be able to really adjust your scene. The closer you get to your beauty shot in render the less work in Nuke you need to do and vice versa. Once you define all your elements it is more straight forward to answer this. General Voumetric Lighting is slightly more expensive than using a proxy light source i.e. you do not necessarily need to use the pyro fire to emit the light, you can use a spot light that has a noise on it. This is really scene dependent. Generally volumetric lighting requires a lot more noise controls to get a smooth falloff of light, but adjusting this to how your flame bounces may be tricky. Really it depends on the setup. Generally aim for a singly beauty pass and then break out each element to render separately. The scene will allways get a bit big, but once you realize what you need you'll be able to remove a lot of dead components. Houdini itself will take anything you throw at it, but your hardware may be a problem. If your scene gets really big then you may need to split out elements to be processed on a farm. Generally speaking there are years worth of things to learn about, and then just when you think you have mastered it all, a whole new wave of stuff will come in. As far as straight workflow for your first project of this scopr, I would design each element currently in a separate scene file, and have a scene assembly in another. Imagine you are working on a team and you would pass this to a lighter and then a compositor. You only want to pass off the elements you need, and since you are doing R&D there will be a lot of stuff you need to figure out. Also this allows you in the scene assembly phase to collect the final outputs of each element as a cache. Generally you never render an FX direct from it source but from a cache. You do not want to pay to run the FX each time you need to render. This also allows you use instancing and delayed load more effectively. Good Luck. -Ben
  7. Awesome, it will be nice once that bug is vanquished.
  8. Ah OK I can repo no problem now in 16 and 15. My misunderstanding on what you were doing. Send that to SideFX as a BUG for sure, include the video for the repo. The code below you pointed out before is referencing the wrong node I believe, now that it is promoted. As I understand kwargs(which is piss poor) are for the the current node context. This should be a link to the original node to work as I would understand. As this would happen every time you promote this group from the color node, I would classify it as a bug. I believe it is looking what type of entity/group type you are looking for i.e. primitives, edges, groups... So in short on the color node if you also promote up the parameter entity this menu would work. Or you can force it by using the line of code like from the point sop (hou.geometryType.Points,), or (hou.geometryType.Primitives,), or (hou.geometryType.Edges,). In addition I think you can redirect the kwargs['node'].parmTuple('grouptype') to reference the value of the parameter in the HDA... But you know brain fart on my end, LOL. import soputils kwargs['geometrytype'] = kwargs['node'].parmTuple('grouptype') kwargs['inputindex'] = 0 soputils.selectGroupParm(kwargs) The catch I found when i tried other nodes, is some of them worked.... so it appears not every node uses the same code in that context, plus people may be promoting up the other referenced parameter too. Which is why I think you may have discover this where others have not bothered to look. Below is the code from the point1 group if you promote it up, this only works on points and does not reference any other types i.e. primitives. import soputils kwargs['geometrytype'] = (hou.geometryType.Points,) kwargs['inputindex'] = 0 soputils.selectGroupParm(kwargs) The delete node's group would also error out as if your promote it up, then it errors the same too. Here is the full error output. This would be the specific error code to also share with SideFX. They could report as designed... however the error code seem to fall back on edges of all things, the least supported type. Maybe request in the least it to default to the last chosen option, i.e. the colors default is point... idk, they would know best, as that is way farther down the rabbit hole. Traceback (most recent call last): File "Parameter Scripted Action", line 4, in <module> File "C:/PROGRA~1/SIDEEF~1/HOUDIN~1.480/houdini/python2.7libs\soputils.py", line 219, in selectGroupParm if hou.geometryType.Edges in geotypes and len(geotypes) > 1: TypeError: argument of type 'NoneType' is not iterable Good find!
  9. I just tried the same scene in 15.5.480 and it still fixes it. You might have a red herring, as in your issue may lie elsewhere. You can copy and paste the entire text from the error message as I can not repeat it, but it is probably being caused by something else you do not notice and just causing the error to appear there. At this point I would suggest discarding the HDA, and making it from scratch. That would 100% cure the issue. If it doesn't then the issue certainly lies elsewhere, and you need to look further.
  10. Yeah this is the fundamental issue, as it does no clear the view ports *buffer/cache. *(There is a post where I was corrected on this term, but for brevity sake I'll use it again). The issue has been to make this issue repeatable where you can actually submit it as a reproducible bug, they can fix.
  11. Ok so I got unity up and running. For my own amusement this post is for me to keep track of what i am doing, and encase anyone else comes across this. I tried the straight FBX material method to expose the inherent export bugs/limitations. I used Maya 2017 as a secondary test program besides Unity 5.6.0f3. For my example scene in Houdini I created a geometry node geo1, placed a testgeometry_rubbertoy1, I set the scale to 100 and TY to 66 (it's small in unity example scene) and began my exports. /obj/geo1/testgeometry_rubbertoy1. I tested with both fbx exporters the one in the File > Export > Filmbox FBX... or through /out/ with a Filmbox FBX rop so /out/filmboxfbx1. I didn't try the script methods with these test as it's really the same code. I set the output file to $HIP/materialTestHoudini.fbx and selected the Export node to /obj/geo1. For reference: http://www.sidefx.com/docs/houdini/ref/windows/import_fbx http://www.sidefx.com/docs/houdini/ref/windows/export_fbx http://www.sidefx.com/docs/houdini/nodes/out/filmboxfbx http://www.sidefx.com/docs/houdini/commands/fbximport http://www.sidefx.com/docs/houdini/nodes/shop/v_fbx From Houdini to Maya/Unity: By default it will export a material link it appears for Maya with a diffuse texture but the material path is still the native HDA reference, plus the spec texture did not come across. In Houdini HDA opdef:../..?toylowres.jpg to this in Maya opdef:/Sop/testgeometry_rubbertoy?toylowres.jpg So I allowed editing on the rubbertoy and saved out the texture to $HIP/toylowres.jpg, and changed the link to that from the above and the color texture comes across. Albeit, while a few textures come across this is certainly not a good material exchange accept for some really basic parameters, the phong shader was selected with houdini specular lighting model, and incandescence was map from subsurface color, this seems to be a bit of material limit. Substance definitely is a better method. So in unity the material link does come but definitely not materials as you said. So what we did at most studios was write a script that would at least take this materials link and do a look up and replace the material to something pre-built. But that is all ways a pain, and a studio one off. I tried next to just export this same exact model from Maya to Unity, and it failed too. Which this should work, however... it's lunch time so i'll edit this when I get back. ...OK so I was looking into why the texture issues happens in Maya too with FBX, I found this blender post and it makes sense. http://answers.unity3d.com/questions/124817/why-is-my-imported-fbx-file-not-showing-textures.html Mischa is right, FBX does not export textures and you have to import them into your Unity Scene, but if done right you can reload your FBX and do not have to manually assign them to the materials. They will find the links with the right materials. I always have my folder setup like this: Assets/MyModels/ModelName/ FBX imported file which creates a materials folder, I add a textures folder, my 3d model also pulled the textures out of a textures folder next to the model. after I dump the textures in the textures folder I reimport the FBX and wolla! all the textures are assigned. So this will probably work in the end too with Houdini Textures. Need to give it a go, but if I'm thinking right this will be the same with Houdini Engine. BINGO! Take that FBX! The whole material parameters don't map, but that goes back to common mapping issues, and why substance is the bomb.
  12. So the error you are having is in the on your parameter select_some_polygons on the Menu > Menu Script Hscript code, your is on the left/top and the new one i promoted up is on the right/bottom for the opmenu script to work you need the name of the parameter at the end. http://www.sidefx.com/docs/houdini/commands/opmenu so by taking your script and adding group to it, it will work as that is the name of the parameter it is referencing. opmenu -l color2 group group_test.hdanc I didn't replicate the python error, so I can't help on that. Hope that helps.
  13. #neverwin lol, I don't have Unity or Unreal on this machine, let's see how long it takes to install... Is the texture just no showing up in the corresponding unity shader? or is the shader not being assigned?
  14. I haven't done the straight FBX export outside of RBD stuff in a while, so some one else can chime in on that. It should work though... As far as the HDA transfer of materials via Houdini Engine to Unity. This is what i have been using for the last few years. In H16 there is a "Houdini Engine" Shelf that has a shortcut to drop the Attribute create node, with a primitive string attribute called: unity_material, and the string example or relative/path/to/.mat/within/your/unity/project/including/the/.mat/extension. The below is a simple tutorial you can skim through for more details on the subject with unity asset creations. There are example files to so you A and B what may be wrong.
  15. Lol, missing the .hda/.otl, too. So I can't say specifically what is wrong with that setup, share that too, and don't lock it. At any rate, If you just promote the group parameter through the Edit Parameter Interface/Edit Operators Type Properties as you did then the group drop down menu should work by default. You should never have to touch the Action Button script area. The only code to edit would be in the Menu > MenuScript dialog if you wanted to edit it i.e. opmenu -l color1 group that is in hscript to reference the other group menu. You can do this in python, too. As for using python to create it from scratch, one of the issue with the drop down menu, is you need a Label and a parameter value as an array in python. I'm probably butchering the python terms there just then. However, the label appears in the drop down menu, and the parameter value is what appears in the editable field. I think that may be stretching from the issue. Alternatively you may just need to re-create the hda again. Sometimes shit just breaks and a clean rebuild will fix it. Example are the attached hip and hda. GroupMenu.hip GroupMenu.hda