Jump to content

LaidlawFX

Members
  • Content count

    1,017
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won

    25

Everything posted by LaidlawFX

  1. With Houdini Engine, you used to be able to use groups and enable an option on the Houdini Interface in Unreal to separate them based on groups. So depending on how old your version is you could do that. I'm not sure when they made the change, but now you just put your geometry into separate object nodes. The simplest way to do this is to create a object level subnet and inside create all your geometry in one geometry node called data or something, and shut of the the object level display parameter. Then create a new object for each element you want to separate and place object merge nodes in there. If you think of this in context to how Maya and Max works it will make more sense, one object equals one mesh.
  2. Measure length ?

    https://en.wikipedia.org/wiki/Topographic_map
  3. Measure length ?

    In addition to what Jesper said, even if you don't model to scale, but know the relative conversion ratio of your model the value should be correct. For example, if you are taking terrain data and scaling a mountain to the correct size, you can not do it at real world scale due to precision issue of 32/64 bit precision, however, you can scale your object by a percent and be good enough for CG.
  4. Measure length ?

    You can use the length vop from the original surface to the displaced surface and export to an image plane. If you have not changed scene scale, and your model is to correct units, the displacement should be in meters.
  5. Blackmagic Design Fusion, output space for imported EXR

    Houdini will export in Linear by default. The preview window will do a basic gamma 2.2 curve as I understand. Docs here : http://www.sidefx.com/docs/houdini/render/linear.html So you would not want a custom that just does a general curve not the "standardized" curves in the drop down.
  6. The file sop has been upgraded in recent versions so you can import geometry directly with out funny values required that the importer uses.
  7. Control Energy Conservation ?

    If you are picking the color in Houdini you are picking it in linear space. If you want to pick it as a float versus a vector, you can wire a float into the input. Then you can enter just .02, or just enter .02 in all three values as the values are 0-1, not in 256 numeration.
  8. Control Energy Conservation ?

    In general you should not use any non-linear textures in the shaders with a true PBR workflow. Then your float value and pixel values will line up correctly. Houdini is setup to assume a linear light workflow through the whole program. When you author them in Photoshop or whatever program you should apply the correct method for your texturing workflow upon export, or as a post conversion, so they are read in linear. Houdini nor most DCC have the full range of options to compensate for all of the different color spaces a texture can be authored in. Generally you can apply a gamma shift or sRGB shift in most programs. Houdini to my knowledge still does not have a sRGB to linear vop node to compensate. Though if you are worried about this already to this extent, you should do the correct conversion from the export to begin with then all the math will work out. I'm sure you are aware of Linear Light workflow, but this document speak directly to it as far as Houdini handles it : http://www.sidefx.com/docs/houdini/render/linear.html It's helpful as a reference guide, the core math is slightly beyond me to explain. I still can't describe a quaternion, lol.
  9. The FBX writer is not very sophisticated in Houdini. You can use the gamedev RBD FBX exporter and it will export it by name.
  10. Control Energy Conservation ?

    If you look at the BSDF in the principal shader you'll see how it controls the levels. I can't explain if mathematically, but it will balance the load for you. If you work with all the sliders for the different contributions and pretend they all represent part of a percent it will make sense. If you overload one of those values or all of them they will progressively flatten the values.
  11. How much instances can I render?

    Looking at the scene file, having depth of field, motion blur, pixel samples set to 8 by 8, diffuse limit to 1, on your ROP will slow it down a bunch. You should balance your samples more. Your tree is insanely dense at 106,318 prims when fully unpacked. You definitely need to do a second pass at your assets. Your instanced tree for a forest is not a hero tree. Even for a hero tree this is way too dense. You'll certainly want LODs too. Especially for the dense part of your forest. It's not surprising at all why it is taking so long to render.
  12. How much instances can I render?

    Collapsing the amount of calls is a very old fallback, still used in optimized renderers like game engines today. Generally it's done in a pre-compile pass with out one's knowledge. I'm guessing MtoA is collapsing a bunch of those calls under the hood if you are actually instancing leaves on top of instanced trees. Are you using another plugin to actually set those up, or are you doing exactly as described? Mantra is smart, but since it has a lot of flexibility you can still make it choke quite easily. Not sure about the ability with apprentice on something of this scope. So there could be limits I am not aware of. You can batch your environment into as many chunks as you want to best feed it to any engine. Whether your delayed load is a single tree or a cluster of trees just depends on your environment. Pre-baking into different IFDs(same as .ass) will help load issues for sure. How you batch that is up to you and varies per a scene. The Delayed Load is a pointer file for those pieces of geometry in the final .ifd for the scene. You can look at the ifd for the scene and see the actual path to that file as opposed to the geometry in the ifd. If your ifd is larger than a few mb you can tell you'll have issues already. Make sure you convert your incoming geometry into a native file format like .bgeo so it does not need to process it at render time. You can use a Mantra Archive if need be that will pack the materials and strip the attributes, too. You can do this in SOPs, too. .bgeosc will be the fast and most compressed for mantra. Make sure you are not using fbx or .obj as it will need to do conversion each time. You can also use alembic delayed load to avoid this conversion issue too. Anytime a computer program can not keep the process in RAM and has to save it disk should be a large warning flag. When a program goes from RAM to saving on disk process time will jump dramatically. So you need to balance your processing load correspondingly. You can change the $TEMP and $HOUDINI_TEMP_DIR to an SSD drive, but like I said if you are fallign back on that it's a bit worrisome. One of the things with time may be the density of the meshes in the scene. You may want to use some LODs. A render engine can reduce one large poly to a pixel easily, but a large number of polys in a pixel it will take longer to process. From games processing of forest what type of density do you have in your leaves is important. Are you leaves 100points, or only the bare minimum for the shape. Also are you using Alpha or Opacity to handle any texture based leaves? Opacity means more tracing. Which leads me to another culprit on time. I take it you are using an environment light for the scene. I would say check how many samples your are sending out from the light and mantra to get the render smoothness. One really dense meshes this can eat up more time. I actually do not know if you can use delayed load on copy to point. But you can use the instances attribute on your points to point to a any object that has the delayed load shader assigned to it. I'm guessing the Delayed Load may not be the final answer. You could actually be having a few other problems too. I admit I did not actually look at your scene file
  13. How much instances can I render?

    The nested instances would definitely be an issue as that is a lot of calls per an asset. That's definitely a X^# computation nightmare. The math is similar under the hood for sop and instancer, but people tend to do very dirty things in sops as they don't understand how to work them, nor do they work with them cleanly. You can merge and do anything in SOPs, placing a pyro sim with a instance cloud. Being a CG janitor for years I have seen people screw that option all the time. Generally it never happens in Object Instancer setups. You can then tweak the render settings on your render engine a lot more efficiently. Even though you can do something doesn't mean it's the best method. To set up the Delayed Load, if you are using the object instancer. In a material net drop a Delayed Load Procedural and assigned your flattened geometry. On your instanced geometry node go to Render > Geometry > Procedural Shader and assign the shader. What this should do is load the object into memory only once like a packed geometry, but as the render buckets move into say a blank area it will drop it from the memory. Or in the case of more tree types you would only load the geometry you need. Additionally you can balance your render tree and bucket sizes to compensate. In some case you may just want to brute force and have it loaded once in memory and not drop it ever as the loading and unloading to memory will cause more time than it's worth.
  14. How much instances can I render?

    You should probably use the instanter node at the object level instead of the copy to point sop. In addition you should use a delayed load archive to to set up delayed load archives for your scene it may not be required, but it should help by keeping it in memory better. You should be able to render millions easily.
  15. Heightfield Isolines?

    I think you need to convert to geometry, and then make slices. I don't think you can go from volume straight to curves, i.e. an n-gon.
  16. Debugging with Houdini Engine Debugger + UE4

    I'm not a Unreal expert, too much time with proprietary engines unfortunately. I highly suspect you can do that though. Plenty of games build world's in Unreal as such, it might just be a bit of google Foo. You may hate me for saying this though but since you said it was geometry issue. Houdini definitely needs a fix in this case I completely believe. HOWEVER, the system has been used for years in production up into this point. So you may just have an asset management/approval process that is more the culprit. Game engine's really care a lot about the mesh's provided for performance, more so than render pipelines. So they don't handle outside the norm meshes well. I've had issues like this before in proprietary engine where this smells more like an edge case. Building up good wrappers around exporters takes a lot of work, so submitting this edge case is certainly good. So you may fix your troubles with a standardized pipe. Apologies if that is a sore topic, it generally is in production.
  17. Debugging with Houdini Engine Debugger + UE4

    Hey man certainly send this into support at sidefx.com, or use the submit page on the website. If it's a crash like you say it is then I can only tell you how to avoid it. They can fix it. In the email subject say BUG: Unreal Houdini Engine Crash. And for the body explain the repro step by step and attach the assets and Geo like you did. If it's a geo issue like I think they should be able to fix it in one of the daily builds quite quickly depending on how busy they are at the moment. I send in about a hundred request a year. They are pretty good at it especially on crash related issues.
  18. Debugging with Houdini Engine Debugger + UE4

    Yeah you definitely have a bug with the Houdini Engine plugin. Well technically it is not a bug with Houdini per say and that of UE4 not being able to handle the diverse array of geometry that Houdini can. They won't fix that anytime soon in UE4 so the Houdini Engine team makes safe catches around the types of "bad" geometry that will cause it to crash. You should send in the example to support, especially if you can get a close to 100% repo case, even if it's slide the slider until it crashes. On the other side I have never had much luck with the subdivide SOP and Houdini Enging to other applications in general. We used to have this issue a lot when i was doing Voronoi Fracture with the Max plugin in for Maya when it first came out. My biggest recommendation would be just not to use the subdivide sop as convenient as it is in Houdini. The subdivide process really depends on clean geometry coming in, and unless you know 100% how they are being created the algorithm that is subdivide can do some interesting things when faced with ngons you can't see. Many programs can not handle the diverse geometry collection that Houdini can so Houdini keeps on trucking. Especially game engine only like very clean geometry for performance sake, and are not designed for funny shapes. For a substitute you can use the divide sop on faces, you can add edge loops( a bit trickier in houdini), bevels, etc. The triangulate options on divide sop are nice option for cleanup too. The Clean Sop and polydoctor can help too if you go down the route of cleanup. I would stay away from cleanup processes to early in your development if you can, triangulation being different than cleaning up overlapping faces and such as a last note.
  19. managing .sim checkpoint files

    Cool Toolset
  20. Debugging with Houdini Engine Debugger + UE4

    Hey Ron, So I'm not sure you are actually using the Houdini Engine Debugger to test your tool. So with Houdini open go to Windows > Houdini Engine Debugger. Set it to named pipe and turn it on. Then in Unreal go to the settings for Houdini Engine, turn off the connection, set the option to named pipe and turn it on. No instead of Houdini running in a background process called HARS it will function through your open Houdini session This way you can do run time debugging of your Houdini functions in Unreal. So the geometry you have imported and the HDA you are using will run in that session. Be warned this is not your typical houdini session, there is no history for example, but you can see what houdini is doing with the imported geometry. If you saved your HDA prior to this test with out your inputs connected to the rest of the HDA, then when you connect the geometry that is causing it to crash you will see what it looks like on Houdini. If your geo is possibly messed up into ngon shit this is a good way to find out. Also you can slowly lead test your hda and see what functions are actually working in the HDA. To help debug once you have this active session hip file you can save this hip. It will presserve the input geometry than came from Unreal as it will be locked. Since the nodes are locked you can share the geometry with out needing to have the Unreal session and all those associated needs. This makes it easy to debug and share. Also the .hda is a seperate file from the .hip. So when you share a .hip without the .hda it will embed the file in the .hip but for practical purposes you can't edit or manipulate this embedded file to share back with you. There are some exceptions for this, but it's easier to just have the .hda in the first place. -Ben
  21. Debugging with Houdini Engine Debugger + UE4

    If it does not crash when you use a box, then it certainly does sound like your custom asset has some geometry issues. You could try and just run that mesh through a clean sop, polydoctor sop, or such and get rid of any n-gons or other trash geometry that it may inadvertently have with out your knowing. If crashes occasionally with the box then you may have two issues. A box theoretically should not cause geometry issues, so it would probably be something else funky happening in the system. The hda is not included in the .zip just the embedded version in the .hip. Also the vertex color randomizer is not included. You can generally strip the secondary .hda when sharing. To make your .hda a bit easier to use you can use the inputs in the sop node as opposed to the object merge. Also save out the geometry from unreal as seen through Houdini Engine Debugger. With your hda to keep it from crashing you can disconnect all the nodes after your inputs "../INPUT" so you can see what that geometry gets imported with the Houdini Debugger. Save that scene and then test what's wrong with that geo or hda.
  22. Debugging with Houdini Engine Debugger + UE4

    Hello Ron, Welcome to the forum! If you got the Houdini Engine Debugger working that's a good first step. If you can share your HDA and or hip with the forum that be easiest to answer questions. It saves from the guessing game. Often reproducing your asset so it can share publicly will clear out the issue on your end too. I'm going to guess your HDA takes inputs and more of a modifier than a generator. If it's a generator you should be able to repro the issue in Houdini easy enough unless you are creating bad geometry. For a modifier like asset, create the same number input on a dummy HDA, then use the Houdini Debugger to visualize the geometry in Houdini. If it crashes then you have bad geo, and should probably submit an RFE with your problem geo, or find out why that geo is problematic. For instance does it have bad ngons? With the geo connected to your dummy HDA save the hip file out so you can shut down the debugger. Then you can debug the scene with your engine geometry only in Houdini. This should make debugging your HDA alot easier. If it keeps on crashing with your asset now, just disable, or remove parts of yoru HDA until you can narrow down what region is crashing the HDA. If it's just locking up but then finishing in Houdini you can run the performance monitor too, but with a straight crash it will only help so much. If you don't have any issue with the HDA exclusively in Houdini with your input geometry. It's possible houdini is producing a piece of geometry it does not see as an issue, but the connection is choking on. This is a bit to varied an answer as we don't know what your HDA is actually doing. Houdini does spit out a couple different logs, but they won't help you as much. The Error code is not common, so you would have to ask support what the code is specificly, but they would need the sterlized example file the same as most people on the forum would to help you debug your issue deeper. Hope that helps. -Ben
  23. Houdini crashing constantly

    Yeah ignore what I said for Romain.
  24. Houdini crashing constantly

    I had a similar issue when I had a bad intel based graphics card. While it sounds like you should have good components. It's possible it's one piece of your hardware that is bad. The other issues is possible bad Houdini preferences, just make sure you cull those. Possibly use Revo uninstaller or some other 3rd party uninstaller. The third radical option is you has some corruption with your OS or third party software another program may share. Generally speaking for a crash like this I do not think Houdini is your culprit in this case outside the possibly bad preferences folder. You might want to go a bit radical and test your components and re-install your OS. If a OS reinstall doesn't work then it's certainly a hardware component that is at fault.
  25. Renderman Shading Language guru ?

    So another not answer, answer that should help you. Just getting back into life again. I went from France back to the US. Oh the fun. Attached is RenderExport.hip It's a simple setup that show the variables flowing from sops to materials to mantra. It has a grid with an array of attributes P, N, uv, rest, foo. Foo is just a relative attribute as it could be anything, in this case is just a copy of the UV attribute. A material shader builder that imports them with an array of nodes that you can cross wire to see how they work. It purposely does not use any of the components of the principled shader core so you can see how the info flows. If you want you can assign the principled shader core and keep unlocking the hdas and deleting the components that don't matter until you get down to these basic components. This was roughly how the shader were written in H9-H14 or so, and at that time was when the transition was easiest from Renderman to Mantra as the 1 to 1 was very apparent. The shader core make that switch a lot harder to see. Which is why most of what I am saying is complete non-sense, besides the fact that I am not actually answering your question directly. lol. There are 4 mantra ROPs each set to the different render engine so you can flip between them and see how the shading works. Also there are a series of different BSDF connections you can make to see those basic components. The easiest way to answer is to keep cross wiring that setup until you understand it. Then the direct RSL conversion will make sense. This way you can see how the data flows across the different components of Houdini. At any point you can RMB and see the VEX of those compiled connections. You can switch between the different render engine no matter what, but you will notice the shading is different due to the inherit difference between the PBR shading, raytrace shading, and micropolygon shading. Look at the fooExported bind export vop and the mantra rop extra image planes and you can see how the variables get passed to the render engine. So now when you look in the Compute Lighting vop you can see how all those connections are made. And how BSDF is broken into it's sub-components to be read by mantra. Apologies again for presenting more a small lego set than an answer. This should help you more. It was the biggest issue going from Mental Ray and Renderman to Mantra. It's that key difference maker, that makes it make sense. RenderExport.hip
×