The gamedev sop-autouv node always gives me a completely unusable result when set to shortest path, independent of the input geo or the packing option: (Version is the latest for game dev and Houdini)

Same question. I have a textured Highres mesh, did a remesh and auto-uvs and now I'm trying to bake the diffuse texture from the Hires mesh onto the remeshed mesh with the new uvs.
Can't find a proper tutorial.

Andr
Unfortunately it doesn't seem possible to do it even with python
http://www.sidefx.com/docs/houdini/hom/hou/GeometryViewport.html [www.sidefx.com]
http://www.sidefx.com/docs/houdini/hom/hou/GeometryViewportSettings.html [www.sidefx.com]

I can't see any useful function in these classes.

We'll seems they managed to get at least one aspect of the viewport on par with Blender's….. LOL…
Back to XSI…

Yes, that is nice but doesn't help with resizing… Can we create custom layouts by any chance?

Also I noticed some of the layouts are double, I guess thats just Icons for different resolutions.

How can I drag the vieport dividers in a dual or quad viewport? I want to have the UV view a bit larger than the Scene view for example. I can't find the option to do that.

I think what you are looking for is the “select visible geometry only” option in the options bar when the component select tool is active. The little eye symbol.

So, it is in fact a lot easier in Softimage?

Can we upvote RFEs?

For a still perspective matching can be done by hand relatively easily with a little bit of practice. If you have a movie clip to match you can try blender which has a matchmoving tool.

Nice work. How long did it take? How does the network look?
What about exact numeric point positioning? Across multiple objects?
Are you rendering on a laptop, by any chance?

goldfarb
a python panel would work here.

Do you have one?

colinegreen
I am a brand new (=today)) Houdini convert/learner.

When I load a .fbx which was saved as a number of separate mesh objects with uvs and names, it all comes into Houdini as one object.

Other programs, maya and MODO, load the file as expected preserving this important info and separate meshes.

Is there a way to force Houdini to preserve this and not just import on mesh via FBX?

Colin

More complex FBX files are usually imported as a subnet container which contains all the single objects and the materials. Have you doubleclicked on the object node?

madrenderman
@Doudini yes! I discovered this function today, it's completely hidden and undocumented. It works, a bit rudimental but it works.
Working in the viewport in Houdini is laborious …

…and having to switch keyboard layouts makes it even more so. Especially if you switch between applications a lot, because there are many things you just can't do in Houdini….

The overall user experience should have maximum priority right now because that would be something all users would benefit from. I'm pretty sure even the hardcore VFX people would be surprised how much faster things can be done with a well thought through interaction concept….

McNistor
So you didn't actually order it, you just happen to like it
DOn't get me wrong, I do not begrudge you or anyone that got their wishes fulfilled to one degree or another in this release, I am among them after all, but I am a bit disappointed in the apparent fact that money are not put where the mouth is when it comes to direct modeling.
It just might be a colossal misread of SESI's intentions starting with H14 or a failure of expectation management from my part regarding the time-frame.

Regarding the align feature itself, if it is as I understood it to be from the video presentation, seems like a more viewport interactive way of “transformation matching” which is currently achievable by clicking on the small buttons at each transform channel's side. The H17 is probably better, I don't deny that, it's just that there are more pressing features that need improvements or downright re/writing from ground up. And this alignment feature, it's very useful when you need it, but you don't need it that often compared to other incomparably more repetitive tools and features. You don't get a lot of mileage from improvements of not that often used tools. So why prioritize it? SESI not knowing what traditional modelers actually use most often could be an explanation.

Anyway, these threads with people going back'n'forth about what features should SESI implement next or whether the new ones have been the best choices, are a glaring consequence of a not so pretty side of our nature and I for one, will take a break from them. I'm limiting myself to filing RFEs, if that.

I says a lot that this one little tool seems to get more attention right now from the community than the whole project vellum.
( in truth I think the people excited about the vfx stuff just don't post it here )

One can hardly criticize the quality and the technical achievement of this update.
It is also obvious, that SideFX are working hard to improve the accessibility of the product. Things like the alignment tool are priceless and like most of the things they invent it is unique and a step beyond what others do. It's those little things that made SI so great and it is good to see this philosophy being adapted by the developers at SideFX.
However, in this light it seems incomprehensible that for example the quadview windows are not resizable. That one has to use awkward key combinations to switch views, that tools are switched automatically without the user asking for it, that there is still not real extrude along spline function, instead of a deform extrusion along spline.
While this seems to be a great release for people doing vfx, it still leaves the broad majority that creates the actual geometry with a software that can almost but not completely replace the traditional packages for them. Which isn't enough to fully switch.

I would like to see one release that solely focuses on interaction, viewport, scene-management, multiobject editing and render layer and one or two additional modelling tools.
I might try to use the auto-uv feature in the future a bit and wish I had the alignment tool in SI but there is still not enough to make Houdini my main app. I know the SideFX devs could do so much more for the user experience. One can see that the mindset is right. But that makes it so painful to see how little they actually do in comparison what goes into more VFX.

How's it going @szmatefy?

I found how to tell HQueue how to render Job in the order they were submitted. Another default that shoudn't be the default.

In the hqserver.ini there is this entry:


# Algorithm to use when assigning clients to jobs.
# Available options:
# sharecpu - Assign clients so that the number of CPUs is distributed evenly
# across the jobs.
# fifo - Assign clients to the job that was submitted first. When the job is
# finished then assign clients to the job that was submitted next.
hqserver.schedulingAlgorithm = sharecpu

The default is sharecpu which distributes the jobs evenly between all cpu/clients. Set it to fifo (first in first out) and you get the “normal” renderfarm behavior one job (scene) after the other. Now you can start 20 jobs render in the evening and be relatively sure, that they are rendered in the submitted order without using priorities or dependencies.

twod
That last issue with the locked camera view grabbing the view of the viewport the mouse was released in when in quad layout is fixed in 16.5.613.

Good to know. But as I said, it would be helpful to know which issues have been reported already. Would have saved me a lot of pain..

fuos
Maybe H17's new timeline will help the auto-commit in some way. Definitely a good preference to know about!

Update: 16.5.613 is meant to fix a camera drag'n'drop bug

It would be very helpful if we had a list of user submitted bug reports so we can look something up quickly if we find an issue, and confirm it. Like starcitizens issue council, if anyone is familiar with it here …

As I recall there was some work done on the viewport and the camera for H17, so it doesn't make sense to report anything until we've actually seen H17.
For the auto commit, yes, I know that isn't a bug. It's just a non helpful behavior in most cases and shouldn't be the default.
There is a lot of work to be done on UX that shouldn't be too hard to do. I just think there is not enough focus on it in the development right now.

The3DStig
Using redshift these days as my main renderer and I'm very happy with its speed!

I have noticed a big slowdown however when using Hqueue. When I render from within Houdini I get 2 to 3 seconds per frame, submitting via Hqueue I get about 13 to 14 seconds per frame. Still very very fast, but that seems like a huge slow down! (Using Houdini Indie if that makes a difference)

I suspect it's because Hqueue opens and closes an instance of Houdini per frame. I've already got Hqueue using a local install of Houdini (as opposed to a network location).

I'm just using a render node to process these and while I could just manually render each scene from within Houdini, it'd be nice to have them all queued up so I don't have to start each one after the other has finished.

Is there a way to have hqueue keep the instance of Houdini open to render a whole sequence rather than open/close per frame? (assuming that's what's happening)

Thanks!

Are you loading Houdini from the distro folder, and is it somewhere on a network drive?
You can point the submitter to you local installation then.
Also bear in mind that HQueue starts Houdini fresh for every single frame which is not the case when you render from inside the application. Not very efficient and you can not create chunk of frames or anything like in a real Renderfarm.