Jump to content

LaidlawFX

Members
  • Content count

    1,017
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won

    25

LaidlawFX last won the day on October 15

LaidlawFX had the most liked content!

Community Reputation

196 Excellent

2 Followers

About LaidlawFX

  • Rank
    Technical Director
  • Birthday 02/23/1985

Contact Methods

  • Website URL
    http://LaidlawFX.com

Personal Information

  • Name
    Ben
  • Location
    Pacific North West
  • Interests
    Getting away from the computer
  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.
×