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

    733
  • Joined

  • Last visited

  • Days Won

    15

Community Reputation

97 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. I unfortunately don't have the time to create an example set up for the fbx workflow at the moment. So hopefully some one else can help you on that. If you look up basic rigging and fbx rbd export tutorials it's not a terrible setup to do. An alternative if you are familiar with another package like Maya, is to export via fbx with with out a rig as a geo cache or as an alembic, and then rig in the other package. In general you are assigning a bone to a point/vertex. With the static geo, or rest position, as your T pose. So you can iterate over each point attach a joint(usually via python or another script language), and then bake the position transform of the deformation as a key frame on to the T pose, minus the difference from the default position. If you forget to subtract the difference from the T pose, your T pose should be at Zero. Hope that helps.
  2. As far as making it loop, in the Houdini 16 game shelf there is a create loop shelf tool you can use. As an alternative stitching method, I have one one on orbolt that forces the ends to overlap. http://www.orbolt.com/asset/LaidlawFX::BlendLoop::1.0 As far as exporting it to unity there are three methods, two I would recommend however. The first i would not recommend is blend shapes in unity(not worth it). Moving onto better methods, lol, you can use fbx where you assign a bone per a vert and transfer the position information to the bones from your rest position. This is a very traditional method, as you can import it via the normal fbx pipeline. The alternate more efficient, but at this current moment takes a bit more effort, is to do it by vertex shaders i.e. fancy displacement shader. On the game shelf there is a tool called vertex texture animation i believe. This is currently only has the unreal shader provided, however, you can easily mod it for unity. If you wait and poke SideFX they will develop the unity shader for this. What this method does is encode each transform per a joint into a texture based data format. Then you export the geo via fbx, the transform via this exporter as soft, and you can copy the unreal shader from the tool mod it for unity and apply the shader in unity. The link to that odforce conversation.
  3. What build number of houdini 16 were you installing? The 16.#.### Also what OS? It's possible it is a bug. You can tell sesi about support (at) sidefx.com. Test it on a lter daily build to see if they fixed it yet though.
  4. Cool if you want the banking.
  5. If you want to do a test, you can bypass your $HOME\houdini15.5 by calling it $HOME\houdini15.5_BAK, to check where your $HOME is go to the textport pane and do echo $HOME. If you have set your $HOUDINI_PATH you can bypass that too. After relaunching houdini, if the issue goes away then it's something in your custom directories and other tool sets, and then you can slowly engage each directory to see what is wrong. I'm guessing the first one to test would be $HOME\houdini15.5\otls_BAK. If it is still calling that issues after you have bypassed those directories and when you open a new scene, then you should probably reinstall Houdini :/ Also get the latest production, or daily build of houdini as it may be related to that specific version.
  6. That should not be possible, as the hda would have to load in order for it to do that type of check. Is that hda in another hda? or is it getting created in a preset workflow? Also this will keep happening if you switch back and forth between major versions with a scene file due to the fact that parameter only exist in one version.
  7. set v@up = {0,1,0}; to brute for the the up angle, and use the polyframe for N like Atom said. This will keep the top edge of your sprial flat if it is going up in the Y axis.
  8. Yes, but it may depend on how big your crowd is. If you need to use complex instancing methods to render a very large crowd this will probably not transfer. Especially the more complex you go, it will be easier at a certain point to just transfer the shader and lighting setups to Houdini from Maya. If your crowds are relatively simple you can just brute force transfer them back with alembic. So if your crowd is only say a hundred- you can probably transfer it back to Maya relatively simple via alembic, if your are going towards the thousands+ I would lean to just rendering it from Houdini.
  9. Yes, the 90% of time you see that dialog is because you switch versions of houdini and new or old parameters exist. Once you save it and keep on working in that version it will go away. Alternative the other 10% is when an hda is no longer linked to the scene file and it becomes embedded.
  10. In Maya or Houdini? In Houdini look at the MMB of the voronoi fracture node and it will list the number or primitives in the group. In the geometry spreadsheet it will show it in the primitive list with 1 included, and 0 excluded, they should be mutually exclusive inside and outside. If you want test one frame export with .obj that should 100% work in Maya showing the faceset groups. Using alembic there are a couple of import methods that might matter. Drop a simple example test geo and the version of Maya you are using if you need more details from that perspective.
  11. Generally when people do this shot they just use a card with the image of the clouds due to the distance from space you are at, as you can hardly see the depth. If you are flying in on the planet you'll just use a white dissolve as you hit the white cloud layer and miraculously appear on the other side due to edit cuts, as the physical passage of a camera through the cloud deck would take to long normally. If you flatten the image, we just used a one voxel sized simulation to get the motion to continue from the original source data. Then we kept the data as an image or geo to wrap it back on, and the convert it to voxels then with something like point to.voxel, but extremely dense to keep it thin. Make sure you cull the side you don't see inorder to increase density it you stick with volumes.
  12. As an alternative problem with same bloat issue. If the tracker program is placing nulls for it's tracks, an increasingly large amount of nodes can make the file size jump extremely large. The same happens when large fbx or alembic trees are imported into the scene, especially if it keeps running tracker say on load, or you keep adding fbx/alembics to a scene. If you dump the tracks to a native bgeo cache, and remove the nodes the scene file would shrink.
  13. Look at the face sets in the outliner underneath the rest of the geo for those groups.
  14. Yup! Don't do it with a multiply node for sure, or the compile will fail. However leaving stray parameter of bind vops works, especially as pass through nodes. i.e. creating random additional ui parameters, or shuttling attributes from sop to shop/vops to out. I will put a small * as it may be a bit more dependent where in the new material networks in Houdini 16 you place them, I think they will still need to be in a material shader builder to be picked up the same way.
  15. Don't worry about the dif input in those shaders the only thing you need from those shaders are the floating, JKID or Op_Id parameter nodes in the shader. The rest of the principled shader can remain the same.