I have no idea what is going on behind the scenes, but threads like this make me feel *very* uncomfortable. Jeff has asked you (“madcat117”, whatever that is supposed to mean) some questions in order to figure out what might be going wrong. He is showing, by this, a lot more cooperation and interest in users' issues than most other (3d-)companies I have been in contact with. Yet, from what can be read in this thread, you (“madcat117”) are completely and 100% ignoring the questions, making it almost impossible for SideFX to help you.
It may not have occurred to you, but your setup is *not* the typical use-case scenario. I am absolutely sure that SideFX has interest in solving the problem *with* you, but some decency on your behalf would go a long way.

I apologize sincerely for stepping in. This is not my thing to say - the only excuse I have is that I *hope* SideFX can keep up their user orientation even *with* this user behavior.

Marc Albrecht

In my experience, the “plant-topic” is suffering mostly from lack of (financially backed) interest. I have spoken to a couple of developers involved in (in-house) projects for realistic plant-creation-tools and while developing up to a working proof-of-concept stage is more or less trivial, making the output LOOK GOOD is what takes time, experimentation and research (in a context that in ancient time was called “nature” and today is considered a service provided by Facebook).

I have used Grove a couple of times and really liked its approach, however, its pythonesque single-threadedness makes it almost unusable, as you have to experiment with settings to get the looks just right. Yet, I am pretty sure that some of its ideas could be converted into multi-threading and while this wouldn't make it FAST it could improve on the user experience quite a bit. The question is: Who is willing to pay for the development needed? I don't see anywhere close enough to sufficient sales being made from a multi-threading-version of Grove, so all development would have to be paid in advance.

Those devs I spoke to said that *in* *theory* they would be willing to create a library (that could then be turned into Houdini nodes) for multi-threading and GPU-based plant-creation that is art-directable (not exactly realtime, but something like 2-5 fps with two million points being placed) if there was “real demand” (as in “income” to be made). Looking at sparetime-projects released for Houdini that have been discussed here on the forum, my reaction was to just shrug and say “OK, I see your point”. With libraries of ready-to-use plants out there it would be almost impossible to break into the Arch-Vis market for example (why use a tool that requires setup when you can use ready-made models?), and that, according to those devs, is the best paying market within this context.

The quintessence, as far as I can see, is: There isn't enough demand for a GOOD plant-creation-tool to create one “for free” within Houdini (that is how I, were I employed at SESI, would see it). There isn't enough demand for a PAID tool, because most customers, who'd be willing to invest money would rather buy EXACTLY the model they need instead of wasting time on trying to create it.
What's left, is: Everyone who needs it builds it for themselves. And since that will always be pipeline-oriented, it probably isn't useful to anyone outside.

Personal sidenote: It would be cool if there was a creative, constructive Houdini community where such a project could be initiated, a small group of able devs would meet or frequently connect and build tools like this out of their personal interest, selling it once its done (but not for the money). In my experience, the able devs are employed and working overtime, the ones who “want” such a tool cannot help in building it and those with the money to support the development have different interests.

Sorry for the negative view, feel free to downvote me

Marc

A few thoughts - if I may - from my attempts to replace the CLI version with the Houdini plugin (by the way: The new compilation works!)

Wish for: Warning “no GPU found”
- for whatever reason on my Surface Book 2 the NVidia GPU got switched off while using Houdini/RC-plugin, which led to the crazy situation of the model having been built (on NVidia, because RC is using GPU only) but created display glitches (on the Intel GPU). After that the NVidia was “gone” and could not be used any more (until I unplugged/replugged the tablet part).
It would be helpful if the plugin could spit out a warning “no GPU found, RC only works with GPU”, because it was extremely hard to figure out what was causing the “nothing is happening” problems!

Wish for: Better progress indication
- we talked about this, I am just putting it down as a note: ANY better progress report would be helpful, and be it in a way that says “no, Houdini is NOT CRASHED, it is merely waiting for RC”. This could be a separate thread keeping Houdini alive (nurturing idle tasks) to avoid the screen going blind.

Desperately needed: Camera exports
- we tackled this before: It would be VERY helpful if the plugin could fire off an XMP export. Currently, we can only extract camera positions, which does help to some degree - but just like with flight logs the position information at times isn't precise enough. If the plugin could simply send a command “export XMP using the saved preference settings” (using a pre-made XML), the XMP stored in the images directory could be read out and their data used. That is how I do it in the CLI-based workflow.
Alternatively extracting (usable) rotation data would help, too

Wish for: Control Points
- again just noting this down: The ability to send in 2d position data to an image plus a Vec3 per point indicated in order to create either ground control points (to match up meshes with imports from different sources using the same world space) or to set reference points between images (to avoid camera-drop-outs, creating more than one component in RC) is somewhat “crucial” for any shot not being taken properly (which at production times can happen).

I hope this is helpful. I would welcome any exchange of thoughts with other users of this bridge solution - be it here openly on the forum or on some private channel.

Over this last weekend, I had freed up the time to work on our multi-scale project in Houdini using the RC plugin. Thanks to the hardcoded license (not a fault of SideFX) this was impossible (license expired). I was able to create a new license.txt file using the SDK, but since the plugin uses its own “linker library”, the new SDK DLLs obviously didn't work …

My perspective for the time being is: The plugin opens up a lot of *possible* workflow improvements to my clients, effectively removing the need to write their own RC-replacement (using the SDK) and instead leveraging the power of Houdini. It is *the* foot-in-the-door for Houdini for their workflows. This is not only for photogrammetry, but for laser scanning AND MORE.
With the current licensing system (RC-side) this has now been put to rest. It is a kill-switch-feature: The need to go online for RC WHILE IN PRODUCTION is already a major PITA - the additional danger of having to wait for new hardcoded time-of-death DLLs has set a stop to this branch of the project. There have been talks about a change in the licensing system for RC, but this is muddy water from almost two years ago - and we can only base decisions on facts available at the moment. For the time being, the RC/Houdini solution is too fragile (again, this is *only* and *exclusively* because of the RC licensing problem).

Privately, I will continue to “play around” with the RC-Houdini-bridged power-solution. For my clients it's back to using CLI licenses for RC - dozens of them.

Master Henry,

this is *so* promising. Anyone vaguely familiar with the pains of rigging (even if what you do is only remotely resembling the term) will *immediately* grasp that this (if performance holds up, which it seems to do) “changes the game”. Not by a few nodges only.

I am very much looking forward to the “full package, sold at considerable rebates through a trustworthy site” ;-)

Marc

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

I'd add to the mix that in Houdini you have a choice of what cloth simulation you prefer - surface-style with energy in points (PBD using grains) with its performance and “vivity” or “volume” based (“volume” as in “3d space”, where mass and thus energy is distributed more realistically) using tets based FEM. And that is just today's situation.

Performance: I don't know Carbon except for some videos I saw (which did not impress me enough to dig deeper - since I am quite familiar with cloth simulations I need more cookies to wetten my appetite) - but there are cloth simulations that are specifically tailored (excuse the pun) for performance (e.g. SyFlex), even at the cost of “realistic outcome”. Because “realistic outcome” often is not what the director wants. Houdini is *not* a specialized high-performance cloth simulator.
BUT.
It is quite easy, even with a superficial understanding of how Houdini works, to iterate on simulations: Start with a rough, low poly, fast, maybe even hand-directed silhouette layer. Then paint in the areas that you want finer detail in and sim only those. Then hand-direct behavior, rig, animate, add more simulated detail.
The back-and-for, the ability to switch between cached data, animated data, simulated data and being able to transfer each one into each other is an advantage that should not be underestimated. (YES, I do agree that in production performance often tops flexibility. I am speaking here from the perspective of a 110% R&D guy!)

Marc

- deleted -

Hi, Peter,

I have *serious* doubts about any Linux version of RC being available … ever.

Marc

P.S. Building a “simple guy's” photogrammetry system inside Houdini is doable - but you wouldn't get the extreme performance of RC, which is the whole point of the pricetag. I'd see the catch22 there: RC gives you (debatably) Agisoft's quality at 50x the speed. If 50x performance is worth the money … go for it. If not … absolutely no need to even try

Marc

Hi, Luiz,

agreed … to some degree

Control points aren't only necessary for fixing alignment problems, but also for any kind of post-alignment (read: world space scaling and positioning). As soon as you are dealing with multi-part-scans (buildings, roads, environments or even high-detail objects) you need to be able to get the photogrammetry output into the same “reality” (positionwise) and that's where GCP come into play.

I wouldn't even go as far as expecting an interface inside Houdini. Because, USUALLY you will have information about where on an image control points are to be expected - either by a shape recognition pipeline or because you simply define your images to be perfect (I am kidding here, am I not).
Read: Even if the plugin only allows for attributes to be set on the images defining control point positions plus their respective IDs (which is how you import them into RC, I assume the SDK “ticks” the same way), that would be a lot of help already.

Marc

Hi, Luiz,

third attempt - the forum loves to kick me out while I am typing a comment.

I hope it is OK to start an open discussion about the open beta. We talked about a few issues that I consider important for any pipeline-integration of RC through Houdini. Control points clearly are one of those points - since if a model is broken up into components (due to poor capturing for example) you NEED to set control points to “glue it together”.

According to this comment on CR's support forum [support.capturingreality.com] you can both import 3d CPD and 2d (image) measurement data. If this works on a separate file (e.g. an XML per image, I haven't tested yet), it should be possible to import (through filesystem, but EVERYTHING is filesystem in RC anyway) control point data even from Houdini.
I will have a go and see if this works as advertised - if so, I can only hope that the SDK exposes the command as well, so it *should* be straight forward to integrate control port import into the plugin (as the current help file says, importing control point data is possible through the UI as well, so it should work. Should.)

Which would be “yeehaw” big time :-)

Marc

@pbowmar - the licensing topic is a … hot one with CapturingReality. In theory a new licensing model is imminent, but has been for quite some time now. For the moment you not only need a license but, due to restrictions of the SDK, also have to jump through loops and whoops to make things work.

If Luiz isn't going to show a typical workflow in demo video soon, I can cook up a walk-through if anyone's interested. That's not because I am overly familiar with the plugin - but I have to use RC frequently …

Marc

Moin,

the constraint type is a property of the constraint, you should therefore find it in the constraint node:



Marc

P.S. In my “add wind to cloth sim” video I am doing the “flag” slightly more tongue-in-cheek: https://www.sidefx.com/tutorials/wind-for-cloth-sims-in-h16/ [www.sidefx.com]

Hi, Pavel,

I am quite sure that a test scene would be helpful. If you can reproduce the problem with some random geometry, it should be easy enough to spot what is going wrong.

Unfortunately, I do not use Houdini often enough to just say “click there and all is well” - I merely believe to have a basic understanding of how baking is supposed to work

Marc

Hi,

> But when I do input a cage all I get is a blank render,

… without having even the faintest idea of what you are doing, this *sounds* as if the “bake” (render) is looking in the wrong direction. If your cage is larger than the geometry you want to capture, the virtual camera placed on every cage-polygon (“face”) needs to point towards the high-resolution mesh, if the cage is smaller, the camera needs to point outwards.

But if what you say is true - that you tried *everything* - then this cannot be the problem, obviously. If you really tried *everything*, I am lost and apologize.


Marc

Hmm … is it me or is the channel too dead even for crickets? Where I disliked the unmanageable noise on Discord, the IRC channel could do with a corpse, so that at least the worms have fun

Marc

Moin,

question: Have you tried using the boolean function? I have had quite some success with comparable “tricky” meshes (3d-scan). Plus the boolean SOP allows you to tag newly created faces.

Marc

Creating a 3d camera tracker in Houdini sounds like a fun project to me. I am going to ask my patrons on patreon if that is a project they'd like me to start

Moin,

it is likely to be painless, based on my experience.

I know that people frequently are experiencing issues with SideFX' license manager - luckily, so far I haven't had any problems with it. When trying out Linux on my PC for the 128th time or so I was able to use the same license I used on Windows on the same machine simply by setting HOSTNAME to the same value it had on Windows. And that was using a different HD with the Windows HD being hidden. So I'd say: You should be safe as long as you keep your system's name.

Most licensing systems base their “lock” on the system's first network card's MAC address. That, too, would not be touched by changing (or adding) drives.

Marc

kevinthebright
Hey Marc, FYI, your Amazon link goes to Amazon's landing page right now, not the book.

Thanks - it seems to be working correctly for me, though …? Maybe you are getting redirected to a different Amazon but .com. The book's ASIN is 1983239305, you should be able to find it by entering either the title or that ASIN into A's search field.

Marc