Moin,

you might want to give more information about what you intend to do. “Free animated FBX” isn't exactly clear - a character could be a toon, could be semi-realistic, could be a low-resolution “game-like” character, anything. “Animated FBX” can be one mesh per frame with non-persistent topology (which would still be usable with Vellum, of course) or a rig … and so on.
There's a baker dozen options at least that might fit into what you are looking for. If you only want to populate test scenes: What's wrong with Mixamo? Sure, it doesn't look good, but, come on, TEST SCENES … if you are looking for semi-realistic animations, renderpeople could be a start. It doesn't look “real”, obviously, but again: You are talking about test-scenes.

Even Houdini comes with “ready-to-use” animated characters, as you know (since you read the documentation), what is wrong with that?

PLEASE provide information about your question so that you can get the help you are looking for.

Marc Albrecht

P.S. There's MakeHuman (you can get rigged characters out of that), there's DAZ (you can convert DAZ to Houdini if you want to), both provide free (animated/animatable) characters … so many options to choose from, so much lack of information!

Hmm … it is, of course, your decision how you spend your time.

I would like to repeat that, in my experience, making oneself familiar with the fundamental workings of a technique one is about to use/learn often helps in overcoming obstacles. You seem to be saying that you “give up” because your efforts in Houdini don't give the results you expect in a completely different tool. To me, that looks like you are mixing two independent problems, only to make things as hard as possible for yourself, instead of learning ONE tool at a time.
There are people who study their trades for years, some say that learning is “a life long thing”. Waving a white flag after a couple of days for one could not make two different tools magically do “the right thing” all by themselves might be a bit short-sighted.

What I take out of this discussion is: It was the right thing to stop producing free video tutorials. People who want to LEARN don't need “this is how you do this one particular thing” tutorials, they need fundamental, basic, complete and highly detailed documentation.

Marc

You need to separate the individual body parts, here: Separate the eyeballs from the head. Obviously, you do not want the eyeballs to be deformed by a weight map that is applied to the head/eyelids. “Group away” the eyeballs/lenses etc. and only apply deformation to “!my_eye_group”.

Marc

Hi, Artur,

I apologize for being confusing - unfortunately, I am not at liberty to go into the full depth of “step 1, step 2, step 3”, but I will send you a private message. You seem to be 95% there

Marc

Blender: I heard good things about 2.8 - now I just have to find someone who is not a hardcore Blender evangelist but only interested in getting jobs done, then I can probably add Blender to my toolbox. The only real pain that thing is causing me is that it does not seem to offer a real API (C, C++), only some Python, minimizing its use in number-crunching-pipelines.

> The Tablet part of the surface book is very enticing to me especially because it gets rid of the drawing tablet setup stage and being on the go a lot would , it would only make sense.

When you remove the screen part on the SB2 you only have one battery side left and are limited to the Intel GFX chip (no access to the NVidia GPU), keep that in mind. I use the table feature mostly to show data/results to colleagues next door - and plug it back in right when I come back.

You cannot upgrade anything internally on the Surface Book. It is closed, done-in system. If you know for sure that 16GB will not suffice, this device is not an option. However, I would consider a cloud setup if you NEED to move that much data. My colleagues usually start with setups from 128GB RAM onwards - and use much smaller systems on the go, because the remote-log-in anyway.

Keep in mind that less memory on the GPU may severely limit the GPU's usability - in theory modern GPU code can fall back to CPU, but in general, you want to be able to push as much memory as possible to the GPU.

Marc

I would like to know what the original poster makes of our comments.

After all, we invested valuable time, trying to provide answers to her questions - the least she could do is say “hmm, doesn't help me at all, I was looking for someone to blame when it doesn't work”.

Marc

The yellow marks above the bonedeform most likely give you the hint - you may have to restash (“stash” node) your data because you changed something “upstream”.
Houdini's sometimes odd “invalidation” logic is one of the hurdles to overcome (and in my eyes one of the biggest ones in general).

Marc

Hi,

thanks for the feedback, really appreciate that someone in this forum “pings back”!

Obviously, ANY “more-or-less-one-click-solution” is better than the approach I outlined above (it just happens that I use a solution like the one I described for a different scenario, so I know it to work). I wonder if it *was* possible to use Mantra (or RS or whatever) to grab environment texture - just out of curiosity.

(I just wish that Blender was compatible with me. It always seems like that tool has a lot of potentials (almost like modo before it got foundried) - one day I will find someone I can pay to teach me how to make productive use of Blender)

Marc

Hi,

just a thought (if I understand your setup correctly): Is it possible that Houdini does not really “see” the environment texture at all, only probes it at rendertime? Or, in other words, is it possible that the environment does not come as an OBJECT with a UV-held texture map to begin with?
If this assumption is correct, would it be possible to “convert” the environment (probably a HDA of some kind) into an actual object and THEN “trace”/bake the texture?

Another idea (if there is a clean way to do this, just ignore my brainstorming): Could you render a few (virtual, i.e. later unneeded) camera projections onto your object, thus bascially creating your own “baking setup”? The idea would be to have something like 8 or more cameras setup around the object you want the environment “baked” on, render a view through those cameras, create a UV map “from camera view” for a proxy object, that would then get the render output assigned as texture (for the UV map created previously) - et voila, you have a “real” object with “real” UV and texture, from which a normal bake should work.

/Brainstorming

Marc

Hi,

no apologies needed

I simply thought that maybe it would help if you first looked into basics before trying to apply “just any” way of rigging (and animating) a face. (As for video tutorials: I used to create those until about last year, but I realized that most video tutorials don't show you WHY something is done, just THAT it is done, so most people don't really learn that much from following a video, so I stopped making them and surely stopped watching them )

In my world “blend shape” = Autodesk terminology = morphs in other worlds = same thing. Basically you store (linear) alternative positions for points and “blend” between the points' original positions and those “morphed” to get to a different “shape” (there you go, everything in one sentence).

Again, from my point of view understanding WHAT does what, why something does what it does and then think about what you want to do yourself: Realistic motion (probably not so much considering the very low resolution mesh you screencapped) or cartoony/game-style animation, basic expressions or fine detailed “acting” etc.

Marc

Moin,

I admit that I cannot follow your thought process - but my assumption is that it might help you to familiarize yourself with how a face deforms in the real world (bone structure, pivots, areas of influence/muscle/fat). Then gather some fundamental understand of what a weight-map driven deformation (using “bones”, as in 3d-control-elements, or joints and “influence maps”) versus blend-shapes/aka “morphs”. Both approaches have advantages and disadvantages, often a mixture of them is used.

This isn't much of a hands-on help, I know, but it seems to me like you want to go your very own way, so the best I can throw in the mix is some “understand the basics first” line of thinking …

Marc

Moin,

I use my Surface Book2 i7/16GB7GTX1060 for software development and occasional Houdini sessions. Cannot say much about Redshift's performance on the GTX, since I run my RS license on RTX2080 at home and don't really render “abroad”. However, I use RealityCapture frequently on the SB2 and can say that the 1060 is only insignificantly slower than the 1080 my client (in that context) uses. I would guess that RS runs smoothly.
Simulations to me are usually physic simulations and don't need that much RAM, but, of course, if you want particles, RAM can only be topped by MORE RAM. Swapping, even to SSD, is no fun. Period.
As for storage room: I have a 400GB SSD card in my SB2 “just in case” (i.e. if the stupid USB3 connectors to HDs fail yet again) and, so far, am happy with using that as a storage device. It obviously isn't as fast as an SSD, but …

Re: Houdini - it's only usable with a 3d mouse or an additional mouse (I use a Swiftpoint Pro when traveling), since Qt's device input is fundamentally bad. Using the trackpad in Houdini is borderline suicidal.

Oh, the GTX 1060 has 6GB, just nit-picking the 6MB mentioned above :-D

Marc

Edit/P.S. I owned a lot of high-end, medium-end and endless-pain-end laptops. The SB2 to me is not only a league of its own, it is so far ahead in terms of reliability, “perceived performance” and comfort that I even installed Linux on some of the other machines (meaning I won't ever touch them again - EVER).

Good to know.

Argh … Python!

You may have to file a bug report for that, I am afraid. SideFX' support usually is rapid in responding.

(The more of Houdini is done in Python, the more cryptic and user-hostile error-message will become, I fear :-( )

Marc

Moin,

doesn't look high poly at all to me :-D

Joking aside: First of, you probably need UV maps. You also need to check which way the virtual cameras are looking. If your higher resolution mesh is OUTSIDE the low resolution mesh, the camera bias needs to look “outwards” - et vice versa.
You may also have to play with the projection type (I cannot remember if the simple baker has that option, it's about “closest point” and “uv projection” etc).
There is a new “games tools” baker available that is said to be “much better” (https://vimeo.com/334054222 [vimeo.com] ).

Personally, I haven't had much luck with any of the bakers in Houdini recently. I had all kinds of clipping issues, direction mismatch (with displacement), lack of UDIM support etc. (so I wrote my own baking tools) - subscribing to this thread for that reason, since I would love to use Houdini for this kind of task.

Marc

Hi,unknown,

> Are you talking about the naming convention of the obj when you say “incorrect”?

no, I was talking about what I wrote above:

MALBRECHT
” - like lack of spaces or one space too much or floating point values where integer indices were expected.

I can create the error mentioned in this thread above by using floating point indices for faces (as an example).


Marc

Moin,

I have had obj-reading issues in Houdini whenever the obj was even SLIGHTLY “incorrect” - like lack of spaces or one space too much or floating point values where integer indices were expected.
The best you can do is strip down your obj file to a minimum to check if there is a formatting issue. Leave out texture or normal information, using the formatting from the file and create one face manually - my bet is that the error message mentioned in this thread is due to integer/floating point misplacements in the file.

Other software is often more forgiving, if all fails you can always write your own obj file importer inside Houdini.

Marc

Hi,

without having looked at your scene file, some standard questions:

- have you made sure that the arms aren't moving too fast for any collision to take place? With legs you often have much slower/denser movement than with arms, often the arms simply “jump” from one position to the next, never really hitting the softbody.
- have you tried increasing the substeps (which, to some degree, can cope with the above)?
- have you tried slowing the time frame down (both on the FBX export so that more 'tween-steps get exported AND on the simulation to match the new fps count)?

Marc

As I have said elsewhere: FBX can be the cause of a LOT of pain in Houdini - I do recommend converting it to native geometry, too, as this will even avoid (random) crashes. Also, I can confirm that often even an unlocked FBX will increase Houdini's scene file size dramatically, whereas an unlocked “bgeo” does not. Unlocked FBX geometry does tend to not get loaded correctly when a recook is triggered.
Unfortunately, FBX is the “go-to” solution for a lot of workflows these days, because most Alembic supports are even wonkier and there is no broadly accepted alternative in sight (don't get me started on “we need a new standard to collect all the standards that exist into a new one just because we can do it”).

In short: Avoid FBX where possible, convert to not-FBX where possible.

Marc

Moin,

according to the search function, this thread [www.sidefx.com] discusses a way of saving out a screenshot from your viewport. Admitingly I haven't tried it, my last attempts to do something like this failed, so I used a flipbook render instead.
I hope this helps.

Marc