Found 46 posts.
Search results Show results as topic list.
Technical Discussion » Multiple objects in FBX export
- Grimwolf
- 46 posts
- Offline
A little late, but I found out you can get rid of the useless null object by just unchecking “Create Root for Subnet” underneath the Source Objects when exporting. Everything now works perfectly.
Edited by Grimwolf - July 11, 2019 14:32:42
Technical Discussion » Multiple objects in FBX export
- Grimwolf
- 46 posts
- Offline
Ah, yeah. I tested adding the geo nodes to a subnet, and it worked. I think this is the best approach so far. The only issue is that it creates a single “world” null object. But having just one empty object in the scene isn't a problem.
Technical Discussion » Multiple objects in FBX export
- Grimwolf
- 46 posts
- Offline
This got a bit more strange.
After some experimenting, I found that I could get the geometry to export successfully if I jumped to the highest level and only added Geometry nodes to the bundle, instead of nodes inside the geo like I had before.
Normally that would be the end of it, except that doing this exports ALL the geometry nodes. Even ones not included in the bundle.
Or rather, it creates a bunch of extra null objects in the scene for anything not included in the bundle.
And this only works if I actually try to export the bundle, despite it including things NOT in the bundle. If I try just exporting the geometry directly without the bundle, it creates another empty scene.
If I select one specific geometry node to export like before, then it successfully exports that one piece.
-Edit- YES! I've found a solution. Hopefully there's a more straightforward approach, but for now this does work.
So I had to use a bundle, and only fill it with top-level geometry nodes as I first described. Then to prevent it from creating a bunch of null objects in the scene, I have to right-click every node not part of the bundle, go into Flags, and set it as “Hidden”.
This absolutely should NOT be necessary, since the Bundle should already be isolating these out of the export. But it doesn't, and this does fix it.
Of course, it shouldn't even be necessary to use a Bundle in the first place. But export by pattern (selecting multiple objects) is a non-functional option which just results in an empty scene.
After some experimenting, I found that I could get the geometry to export successfully if I jumped to the highest level and only added Geometry nodes to the bundle, instead of nodes inside the geo like I had before.
Normally that would be the end of it, except that doing this exports ALL the geometry nodes. Even ones not included in the bundle.
Or rather, it creates a bunch of extra null objects in the scene for anything not included in the bundle.
And this only works if I actually try to export the bundle, despite it including things NOT in the bundle. If I try just exporting the geometry directly without the bundle, it creates another empty scene.
If I select one specific geometry node to export like before, then it successfully exports that one piece.
-Edit- YES! I've found a solution. Hopefully there's a more straightforward approach, but for now this does work.
So I had to use a bundle, and only fill it with top-level geometry nodes as I first described. Then to prevent it from creating a bunch of null objects in the scene, I have to right-click every node not part of the bundle, go into Flags, and set it as “Hidden”.
This absolutely should NOT be necessary, since the Bundle should already be isolating these out of the export. But it doesn't, and this does fix it.
Of course, it shouldn't even be necessary to use a Bundle in the first place. But export by pattern (selecting multiple objects) is a non-functional option which just results in an empty scene.
Edited by Grimwolf - May 29, 2019 20:01:58
Technical Discussion » Multiple objects in FBX export
- Grimwolf
- 46 posts
- Offline
I didn't know Bundles existed. I figured out how to use it by looking over the documentation and made the Bundle successfully. But for some reason when I try to export the Bundle as an FBX, it results in an empty FBX scene. When I open it, there's no geometry inside, and the file is extremely small.
Here's an image of how I have it all set up;
Here's an image of how I have it all set up;
Edited by Grimwolf - May 29, 2019 18:28:46
Technical Discussion » Multiple objects in FBX export
- Grimwolf
- 46 posts
- Offline
I've found a lot of people asking this same question at various points in the past, but I haven't found a single real solution, and I've been stuck on this issue for days.
I'm just trying to export an FBX with multiple objects in the scene.
Unlike most 3D software, Houdini is dead-driven to always combine the scene into a single object on FBX export. I absolutely cannot find any way around this.
There are a lot of reasons someone would want to do this, but my current issue is that I need separate objects to properly bake the maps in Marmoset Toolbag, since I have intersecting geometry. It's similar to the “Bake by Mesh Name” in Substance Painter.
I'm just trying to export an FBX with multiple objects in the scene.
Unlike most 3D software, Houdini is dead-driven to always combine the scene into a single object on FBX export. I absolutely cannot find any way around this.
There are a lot of reasons someone would want to do this, but my current issue is that I need separate objects to properly bake the maps in Marmoset Toolbag, since I have intersecting geometry. It's similar to the “Bake by Mesh Name” in Substance Painter.
Houdini Lounge » Houdini Indie on Steam
- Grimwolf
- 46 posts
- Offline
A lot of people reviewing it seem to have gotten free copies. Is there some way to get a free steam license if we already own the normal non-steam version of Indie?
Technical Discussion » Can't re-edit Topobuild
- Grimwolf
- 46 posts
- Offline
I used Topobuild to retopologize a highpoly model made in ZBrush. Later I made some changes to the highpoly, re-imported it, and re-activated the Topobuild node to try making some minor tweaks to the topology to accommodate the changes I made.
The problem I'm having now is that this does not allow me to actually make any changes. With Topobuild activated, for some reason I can't move any points, I can't remove anything, I can't add anything. The node seems to activate fine and I can still make selections and such, but trying to make any kind of actual change has no effect.
I even tried creating a new Topobuild node after the first one, and it's doing the same thing. It's like the topology is locked.
Does anyone know what would cause this?
The problem I'm having now is that this does not allow me to actually make any changes. With Topobuild activated, for some reason I can't move any points, I can't remove anything, I can't add anything. The node seems to activate fine and I can still make selections and such, but trying to make any kind of actual change has no effect.
I even tried creating a new Topobuild node after the first one, and it's doing the same thing. It's like the topology is locked.
Does anyone know what would cause this?
Technical Discussion » Confused by "Retain Density by View" in PolyReduce SOP
- Grimwolf
- 46 posts
- Offline
I think I see where my mistake was. I assumed it would use the view positions to find the silhouette and maintain that, so I thought that using many points would give it the most accurate grasp of the silhouette.
But it sounds like it's really meant to be used with an asset you'll only see from a particular angle, so you can decimate everything that won't be seen.
But it sounds like it's really meant to be used with an asset you'll only see from a particular angle, so you can decimate everything that won't be seen.
Technical Discussion » Confused by "Retain Density by View" in PolyReduce SOP
- Grimwolf
- 46 posts
- Offline
Is there some guideline for how the points should be placed? I tested it out at first under the assumption that it might work exactly as you described, but when I tried using a large number of points spread around the object in a circle, it actually destroyed the shape and disregarded the silhouette completely. The expected result would have been for it to perform very little decimation, but it was the opposite.
That was actually what initially lead me to believe that my assumption on how it worked must have been wrong.
That was actually what initially lead me to believe that my assumption on how it worked must have been wrong.
Edited by Grimwolf - Oct. 27, 2018 10:28:52
Technical Discussion » Confused by "Retain Density by View" in PolyReduce SOP
- Grimwolf
- 46 posts
- Offline
I'm trying to improve the results I get from PolyReduce, and one feature that seems useful is “Retain Density by View” in order to help preserve the silhouette. The problem is, I can't figure out how this actually works.
The documentation on it is incredibly vague [www.sidefx.com], and I have no idea what the input should even be, let alone how I should set it up. Literally all the documentation gives me on that is “Geometry representing viewpoints”. Are these polygons? Actual points? Do those points need to have normals assigned? Do they have a defined view direction through some means such as normals?
The documentation is useless. It doesn't even give an example of this feature in use. Hilariously, it actually has a link attached to this “geometry representing view”, but the link just goes back to the top of the very same page.
I can't even find anyone talking about this feature anywhere online through Google.
The documentation on it is incredibly vague [www.sidefx.com], and I have no idea what the input should even be, let alone how I should set it up. Literally all the documentation gives me on that is “Geometry representing viewpoints”. Are these polygons? Actual points? Do those points need to have normals assigned? Do they have a defined view direction through some means such as normals?
The documentation is useless. It doesn't even give an example of this feature in use. Hilariously, it actually has a link attached to this “geometry representing view”, but the link just goes back to the top of the very same page.
I can't even find anyone talking about this feature anywhere online through Google.
Houdini Lounge » Trying to improve auto GameRes process from GameDev toolkit
- Grimwolf
- 46 posts
- Offline
Ahaha, I might've stumbled on something wonderful for improving the auto-UV process.
So I think I mentioned this earlier, but both the auto-lowpoly and auto-UV processes can be a bit janky, and when you combine the two the problems become compounded and increased.
The reason being, that auto-UV needs fairly clean geometry to have any chance of giving a decent result, and the auto-lowpoly process absolutely does not give that.
Here's how I'm working around it, though.
I can first create an extremely dense but reduced mesh with a relatively weak PolyReduce, and auto-UV that. Even if the geometry is messy, the sheer density allows the UV process to pick out the best and cleanest lines to split.
I can then run a second PolyReduce, but set the UV seams created earlier as Hard Edges.
This means that, in the process of reducing it to a full lowpoly model, it retains the position of those clean UV edges and reduces everything around them.
I haven't perfected it yet, but I've already been able to get far cleaner UVs this way.
-Edit-
A bit more progress. It seams that setting the UVs as “Soft Edges” is better than “Hard Edges”, since it attempts to maintain the shape and position of the edges, while still allowing the points along them to be reduced.
I've gotten surprisingly good results on hard surface assets as well by hardening normals, and incorporating those normal values into the calculation (which are normally explicitly removed from the calculation).
This causes it to be more aggressive in reducing planar surfaces, while maintaining angles and curves.
So I think I mentioned this earlier, but both the auto-lowpoly and auto-UV processes can be a bit janky, and when you combine the two the problems become compounded and increased.
The reason being, that auto-UV needs fairly clean geometry to have any chance of giving a decent result, and the auto-lowpoly process absolutely does not give that.
Here's how I'm working around it, though.
I can first create an extremely dense but reduced mesh with a relatively weak PolyReduce, and auto-UV that. Even if the geometry is messy, the sheer density allows the UV process to pick out the best and cleanest lines to split.
I can then run a second PolyReduce, but set the UV seams created earlier as Hard Edges.
This means that, in the process of reducing it to a full lowpoly model, it retains the position of those clean UV edges and reduces everything around them.
I haven't perfected it yet, but I've already been able to get far cleaner UVs this way.
-Edit-
A bit more progress. It seams that setting the UVs as “Soft Edges” is better than “Hard Edges”, since it attempts to maintain the shape and position of the edges, while still allowing the points along them to be reduced.
I've gotten surprisingly good results on hard surface assets as well by hardening normals, and incorporating those normal values into the calculation (which are normally explicitly removed from the calculation).
This causes it to be more aggressive in reducing planar surfaces, while maintaining angles and curves.
Edited by Grimwolf - Oct. 25, 2018 13:13:57
Houdini Lounge » Trying to improve auto GameRes process from GameDev toolkit
- Grimwolf
- 46 posts
- Offline
I've found a much better solution to #2, which I edited into my post above.
I've also both found and solved a 5th problem; exploding the mesh for baking.
This isn't included in the baker by default, but I was able to create a way to automatically explode the mesh before baking.
First I group the entirety of the lowpoly mesh. Then I use File to grab the highpoly mesh.
I merge the two together, then use Exploded View. The high and the low share the same part names because of ZBrush, so they get exploded identically together.
Then I use Split with the group name of the lowpoly to separate them again, and input the exploded low and high into the baker node.
I've also both found and solved a 5th problem; exploding the mesh for baking.
This isn't included in the baker by default, but I was able to create a way to automatically explode the mesh before baking.
First I group the entirety of the lowpoly mesh. Then I use File to grab the highpoly mesh.
I merge the two together, then use Exploded View. The high and the low share the same part names because of ZBrush, so they get exploded identically together.
Then I use Split with the group name of the lowpoly to separate them again, and input the exploded low and high into the baker node.
Edited by Grimwolf - Sept. 8, 2018 12:33:40
Houdini Lounge » Trying to improve auto GameRes process from GameDev toolkit
- Grimwolf
- 46 posts
- Offline
I've found a solution to #2.
The solution is actually incredibly simple. It turns out if you use UV Layout set to Single Tile, you can set the Size to non-square values and restrict the area it lays them out into.
So all I had to do was set the height to 0.5, the center of the height to 0.25, and then use Transform UV to stretch it vertically to fill the full 0-1 space.
#3 on the other hand is looking even more complicated than I anticipated. While I can look at the internal structure of the Merge Small Islands node, there's virtually no commenting or network boxes to explain why anything was done or what purpose any particular section serves.
Since this does already exist in the GameDev toolset, I may just have to wait for the developers to fix #3 themselves.
So I suppose I'll be on to #4 next.
The solution is actually incredibly simple. It turns out if you use UV Layout set to Single Tile, you can set the Size to non-square values and restrict the area it lays them out into.
So all I had to do was set the height to 0.5, the center of the height to 0.25, and then use Transform UV to stretch it vertically to fill the full 0-1 space.
#3 on the other hand is looking even more complicated than I anticipated. While I can look at the internal structure of the Merge Small Islands node, there's virtually no commenting or network boxes to explain why anything was done or what purpose any particular section serves.
Since this does already exist in the GameDev toolset, I may just have to wait for the developers to fix #3 themselves.
So I suppose I'll be on to #4 next.
Edited by Grimwolf - Sept. 7, 2018 19:44:34
Houdini Lounge » Trying to improve auto GameRes process from GameDev toolkit
- Grimwolf
- 46 posts
- Offline
I seem to have solved #1.
I removed the blur from the Occlusion node and sharpened the curve so the result would be more binary and more accurately acquire only areas that are fully occluded.
Then I used Attribute Promote to transfer the Occlusion attribute over to the primitives comprised of the points with that attribute, then used a Wrangle to delete all the primitives with a value less than 0.05.
Not only is this a clean result without a bunch of ghost polygons left behind, but it more accurately determines which faces to remove, since deleting the points comprising those faces would lead to ALL connected faces being removed.
2 and 3 are going to be far more difficult to solve.
On #2, I've gotten so far as to create an integer attribute on each primitive defining its UV island by number. I'm struggling now to find a way to iterate over each of them and measure them, in order to find islands that are exceptionally large and long compared to the rest. After that I need to find a way to split it in half.
I think if I can manage this, I can re-use much of the process to solve #3 as well, since it requires me to measure each individual UV island.
I'm going to examine the structure of the Merge Small Islands node to get an idea for how I can measure the islands. Although based on the behavior of this node I described earlier, it may not be set up correctly.
I removed the blur from the Occlusion node and sharpened the curve so the result would be more binary and more accurately acquire only areas that are fully occluded.
Then I used Attribute Promote to transfer the Occlusion attribute over to the primitives comprised of the points with that attribute, then used a Wrangle to delete all the primitives with a value less than 0.05.
Not only is this a clean result without a bunch of ghost polygons left behind, but it more accurately determines which faces to remove, since deleting the points comprising those faces would lead to ALL connected faces being removed.
2 and 3 are going to be far more difficult to solve.
On #2, I've gotten so far as to create an integer attribute on each primitive defining its UV island by number. I'm struggling now to find a way to iterate over each of them and measure them, in order to find islands that are exceptionally large and long compared to the rest. After that I need to find a way to split it in half.
I think if I can manage this, I can re-use much of the process to solve #3 as well, since it requires me to measure each individual UV island.
I'm going to examine the structure of the Merge Small Islands node to get an idea for how I can measure the islands. Although based on the behavior of this node I described earlier, it may not be set up correctly.
Edited by Grimwolf - Sept. 5, 2018 14:33:41
Houdini Lounge » Trying to improve auto GameRes process from GameDev toolkit
- Grimwolf
- 46 posts
- Offline
I've been trying to set up a workflow where I create a sculpt in ZBrush, then automatically handle the lowpoly and UV mapping in Houdini using the GameDev toolkit.
I've largely gotten this to work by following the various guides on it, but I have a few problems I'm still trying to work out.
1) I need to make it automatically delete occluded areas of the mesh so it isn't wasting space on stuff you never see.
I'm currently struggling on this one. I've been able to mark the occluded areas I need to delete by using the Calculate Occlusion node.
This works on a gradient, so I tried to use an Attribute Wrangle to then delete any points with a value under a certain amount.
This seems to work, but the listed number of polygons doesn't go down. I tried deleting primitives instead, but got a messed up result because, I assume, I couldn't find a proper way to convert the point attribute to primitives.
Using Clean seems to fix this ghost polygons issue, but also seems very sub-optimal compared to just not creating this error in the first place.
-Edit- 1 is solved, read below.
2) I need to figure out how to get it to split long UV islands. This is a prevalent issue in stuff like swords, which have long, unbroken planes.
If an island is too long relative to the rest, it has to stretch all the way from 0-1 in the UV space just to fit, and the need to maintain texel density means that everything else becomes super small. Thus you wind up not using the majority of UV space.
I think I can solve this in one of two ways, but I'm stuck on each.
I could find a way to automatically split a long island, which I've hardly been able to wrap my head around without knowing of any means to even measure a UV island. Or I could probably just use non-square textures, but this would have its own host of complications, and I don't see any way to force the UVs into only half the UV space.
-Edit- 2 is solved, read below.
3) This is a tough one; I need to get the UV mapping to create fewer small islands. The GameDev tools have a feature for this built in, but it appears to be extremely buggy and unreliable.
No matter what settings I use, it ignores a very large number of tiny islands, and the settings for this don't even seem to have a consistent correlation with the results they give. IE; a higher or lower setting does not consistently affect larger or smaller islands the way it's intended.
Worse yet, it seems prone to causing severe deformation of UV islands on certain settings.
4) This is a more distant and less serious issue, but Polyreduce tends to create extremely long triangles in some areas.
Equalize Lengths doesn't help this, as it seems to focus only on maintaining a roughly equal surface area. No matter how high I set it, I still get a number of incredibly long and skewed triangles.
I've largely gotten this to work by following the various guides on it, but I have a few problems I'm still trying to work out.
1) I need to make it automatically delete occluded areas of the mesh so it isn't wasting space on stuff you never see.
I'm currently struggling on this one. I've been able to mark the occluded areas I need to delete by using the Calculate Occlusion node.
This works on a gradient, so I tried to use an Attribute Wrangle to then delete any points with a value under a certain amount.
This seems to work, but the listed number of polygons doesn't go down. I tried deleting primitives instead, but got a messed up result because, I assume, I couldn't find a proper way to convert the point attribute to primitives.
Using Clean seems to fix this ghost polygons issue, but also seems very sub-optimal compared to just not creating this error in the first place.
-Edit- 1 is solved, read below.
2) I need to figure out how to get it to split long UV islands. This is a prevalent issue in stuff like swords, which have long, unbroken planes.
If an island is too long relative to the rest, it has to stretch all the way from 0-1 in the UV space just to fit, and the need to maintain texel density means that everything else becomes super small. Thus you wind up not using the majority of UV space.
I think I can solve this in one of two ways, but I'm stuck on each.
I could find a way to automatically split a long island, which I've hardly been able to wrap my head around without knowing of any means to even measure a UV island. Or I could probably just use non-square textures, but this would have its own host of complications, and I don't see any way to force the UVs into only half the UV space.
-Edit- 2 is solved, read below.
3) This is a tough one; I need to get the UV mapping to create fewer small islands. The GameDev tools have a feature for this built in, but it appears to be extremely buggy and unreliable.
No matter what settings I use, it ignores a very large number of tiny islands, and the settings for this don't even seem to have a consistent correlation with the results they give. IE; a higher or lower setting does not consistently affect larger or smaller islands the way it's intended.
Worse yet, it seems prone to causing severe deformation of UV islands on certain settings.
4) This is a more distant and less serious issue, but Polyreduce tends to create extremely long triangles in some areas.
Equalize Lengths doesn't help this, as it seems to focus only on maintaining a roughly equal surface area. No matter how high I set it, I still get a number of incredibly long and skewed triangles.
Edited by Grimwolf - Sept. 6, 2018 16:45:26
Houdini Lounge » Modeling primarily in Houdini
- Grimwolf
- 46 posts
- Offline
I think I've found a better alternative. I'll do my destructive modeling in ZBrush, and just GoZ over when I need procedural tools.
Houdini Lounge » Modeling primarily in Houdini
- Grimwolf
- 46 posts
- Offline
malbrechtWhat kind of a response is that? Hostility aside, it sounds like you're saying “Tell me how they could possibly have done better. But DON'T MENTION C4D!”.
Gee, I have to say … I just had a look at my Cinema4d version and I can tell you for sure that the modeling tools in there are in no way comparable to what Houdini is offering today.
OK, I admit, my C4d version is 1.something and I did only quickly skip through my C4d V2 manual, since I never got to install V2, I may not be up to date.
But wait.
Why should someone developing a tool that is OFFICIALLY being presented as a “work in progress” (look up the term if you are not familiar with it) *know* what exactly some arbitrary other tool is doing? When you are deep in your own project, it is quite uncommon to waste precious time by playing around with neighbor's toys.
Instead of being “underwhelmed” by something that is shown in its EARLY STAGES, why don't you just:
- give constructive feedback like “I would like to be able to do precisely THIS” (not “do it like in xyz”, because for that you can use “xyz”)
- show a demo of what you want to do if you want a copy, demonstrate how it fits into Houdini's “mind” of proceduralism
- explain in what way the tool you want to have would help a large majority of users to become more productive (as opposed to “a single user's wish”)
Yes, I know. This is not how many artists work. Yes, I would love to see “easier” workflows in Houdini all over the place (I struggle hard with nodal workflows, nodal workflows kill every joy of work for me) but I do not expect any developer to just copy something else she does not see any benefit in (for the tool at hand).
EXPLAIN the benefit to the developer. SHOW the productivity gain you would get to management (do a video comparison of a typical workflow in whatever-tool and Houdini). Maybe you get hints from other users at how to BETTER (faster) do it in Houdini?
Sorry for the text-wall. I am currently *underwhelmed* by the type of feedback I see around.
Marc
And proceduralism? The exact purpose of this tool is to allow more effective non-procedural modeling.
Also, the main problem I have with this tool is that it does seem like “a single user's wish”. I've never had to manually place vertices, because I've always found box modeling and booleans to be faster. I don't think I've done that since I was 14 using GMax, and didn't know how to make complex shapes without manually placing points one-by-one.
The tool was presented as a modeling swiss-army knife that would make it much more convenient to model traditionally without constantly switching tools and generating a bunch of unnecessary nodes. But the main focus of the tool is being placed on something that is very rarely, if ever, used. And being done in a very bare-bones fashion compared to the competition, which does little to expand that niche value.
Like some others have mentioned, I think the best case scenario would have been to have it work more like this [www.youtube.com], giving it a wider range of application.
Barring that, I'd have liked to see the drawing tools replaced by more common tools relating to the manipulation of points, like drag-weld and slide.
Edited by Grimwolf - Aug. 24, 2018 09:53:24
Houdini Lounge » Modeling primarily in Houdini
- Grimwolf
- 46 posts
- Offline
I've finished the video, and the tool looks kind of… limited?
I'm glad for more modeling tools, and I can see it helping a bit with some tasks here and there, like more easily filling holes and cutting in edges. But the demonstration, plus the name “polydraw” gives the impression that it's focused on actually drawing vertices in an isometric view. Which is a very archaic and niche workflow. I was actually kinda shocked to see the presenter doing that at all. So having the tool focused on that just seems bizarre.
It sounds like the hotkeys for switching modes are kinda messy as well. I doubt I could use it for a long while without having the hotkeys listed on a second monitor at all times.
I'm glad for more modeling tools, and I can see it helping a bit with some tasks here and there, like more easily filling holes and cutting in edges. But the demonstration, plus the name “polydraw” gives the impression that it's focused on actually drawing vertices in an isometric view. Which is a very archaic and niche workflow. I was actually kinda shocked to see the presenter doing that at all. So having the tool focused on that just seems bizarre.
It sounds like the hotkeys for switching modes are kinda messy as well. I doubt I could use it for a long while without having the hotkeys listed on a second monitor at all times.
Houdini Lounge » Modeling primarily in Houdini
- Grimwolf
- 46 posts
- Offline
Houdini Lounge » Modeling primarily in Houdini
- Grimwolf
- 46 posts
- Offline
I've been reserving my use of Houdini for procedural assets, and doing all my basic modeling for static assets in Modo.
I love Houdini though, so I was considering consolidating my pipeline and trying to just do all modeling in Houdini.
I'm wondering if anyone else does this, and how well it works. I know they added a lot more direct modeling tools in 16, but I haven't used them very heavily.
I know that Houdini would be good enough to get by in, but the relative speed of the work is my real concern.
There aren't enough videos of this for me to get a good grasp of what people can do, and my own experience would obviously slow me down and throw off my evaluation of how fast and easily I can work with it.
I do primarily hard surface modeling. Organic stuff I generally handle in ZBrush.
I love Houdini though, so I was considering consolidating my pipeline and trying to just do all modeling in Houdini.
I'm wondering if anyone else does this, and how well it works. I know they added a lot more direct modeling tools in 16, but I haven't used them very heavily.
I know that Houdini would be good enough to get by in, but the relative speed of the work is my real concern.
There aren't enough videos of this for me to get a good grasp of what people can do, and my own experience would obviously slow me down and throw off my evaluation of how fast and easily I can work with it.
I do primarily hard surface modeling. Organic stuff I generally handle in ZBrush.
-
- Quick Links