Fuchur

Jason has broken his arm a few days ago. He'll try to answer as fast as he can, but it may take a little longer then before. See you *Fuchur*

Very interesting process . Keep the tuts coming . See you and thank you *Fuchur*

Not really... put two grids in the same size next to each other (facing the same way) and put the emitter in front of them. An emitter would now shoot rays on both surfaces and the direction would be changed for both in this situation. With a "master patch" you need to select one patch of each grids to do the same. In other situations an emitter could be bad so, if you for instance put a continous surface in front of it (a box) and shoot on it without being in it for instance. I am not saying that this is a much better approach, it is just a different one. If the master patch is better in your opinion or much easier to implement, I am fine with that one too. See you *Fuchur*

This can be helpful for many situations, but it would only work if everything is really attached to eachother, right? The good thing about shooting rays from a point is, that that does not have to be the case there. See you *Fuchur*

That are two different feature requests more or less. In the end there is no way for the software to know in which way the normals should point in a model. It could be that you want to export "reversed" normals for instance if you want to export a sky-sphere from A:M for a game engine it needs to have flipped normals. Like that you can see into it but you can not see out of it in the game. But a basket ball (which has roughly the same geometry) needs to have the normals pointing out. And this can easily get much more complex if we are talking about more complex geometry or even a whole scene. I am not aware of an exporter in any other software that will automatically be able to determine what you want in every situation... like that it is not wise to make that an automatic process. We are the artists who need to have that kind of control over our models... any other approach is only helping in very specific situations and will give us a head ache in others. But again: This should not be attached to the FBX-exporter. The FBX-exporter should work as most other exporters in A:M too. You define the surface / material / animation / bone-structure in A:M and the exporter really does nothing else than translating that to another file-format. The correct normal algorithm I am talking about is to make the model look like it should before exporting. This is an own plugin-request for a simple but effective way to fix normal problems created while modeling while preserving the full control over what you do. All that talk about COG, Lights, etc. is just too much talk about a very simple thing: You need to tell the correct normal algorithm from where to start. You do not really need to know what a COG is or how a light works. All you need to do is to define a starting point in the 3d space. See you *Fuchur* PS: This is offtopic and only for explaination: I myself find Center of gravity (=> C.O.G.) a very stupid name for what we are taling about... COG is something that is an artifical concept for animators while animating or a real thing for physicist / structural engineer but it is not suitable in an articial geometric modelling universe itself. It can be helpful to create a certain impression for a human, but from a mathematical point of view, it is useless as long as no "real" masses are involved. I like the name pivot much better, because a pivot can be moved wherever it needs to be and has no "defined/fixed" position.

I'd say this could be overcome by just letting the user select for which parts of the model s/he wants to correct the normals for. In general a 3d-designer will not attach eyes (for instance) to the head but just stick them in the holes for the eyes. Like that, the user could easily just make a attach-select and hide or lock everything of the model that should not be affected. The good thing about that approach is, that you can for instance have normals which guide in a special (unexpected) way if you want that. See you *Fuchur*

In the end if you move the COG, it really is no longer important if it is a COG or not. Then it is the pivot part I mentioned above in this example from the selected group. I often work with that when for instance rotating things around other things in the modelling window, etc. But back to this: It is all about defining a starting-point for the rays to shoot from... in which way it is done does not matter. Just give the plugin something to shoot the start-rays from. A Null object, light, pivot (of a group, or even the modelling-window, but I recommend a named group), "moveable COG" (i do not think something like that exists, since it has to be at the center of gravity to be a COG and the gravity makes only then a sense if mass is taken into account), a CP, a numeric input (I do not recommend that) etc. See you *Fuchur*

The difference is, that you can put the light wherever you want. Not only the Center of Gravity but anywhere you like. A very simple example why it can not work with COG in many situations can be seen in the image attached. The only possibility to get the approach to work is to define the point where to start by yourself. This could be done with a null-object, a single-point on a spline (for instance one that is part of a 2-CP spline but is not connected to the patches you want to do the correct normals algorithm on), a pivot of a group or for instance a light. I use the light-reference, because it is easier to understand how it should work if you think of a photon-mapping-approach here, but it really does not matter much. Show back facing polygones is easy... it takes any "polygon" created, copies it and inverts it using the normal as a mirror-point in realtime (or while final rendering, if it is necessary). Concept of normals: It really is not very important in a spline-world, but in some situations, where the calculations are based on the direction of the normal: Exports, especially if you want to create real objects from it (3d-printers, etc.), Hair and Hair-Dynamic Simulations, Smooth-Algorithems for showing smooth surfaces, etc. "So any patch with neighbors that are abnormal (approaching 180 degrees away from what is deemed normative) can safely be flipped." I think this is, what Correct Normals is trying to do (it does a little more, but it is the basic algorithm). The problem is, that the neighbour-patches are not necessarily facing the same way as the first one, because they can be heavily bend for instance. That is fine for them to do, but the calculation has a problem there. And of course 180 degrees is a real extrem... but look at the patches shown on the donut-shape in the attached image. Even if the patches would be flipped, they would not really have a 180° difference, since they already are "rotated" by themselves in comparision to the neighbours. It would only be 150° or something like that... so you have to specify a starting-point for the flipping to get it right. for instance 90° or 120°. The problem is, the more complex the models are, the harder or even impossible it gets to find that number. See you *Fuchur*

You can export the current keyboard shortcuts for your A:M installation by going to "Tools > Customize > Keyboard" and pressing on the "Export"-Button. See you *Fuchur*

COGs will not do the trick Rodney... make a tube-construction with several tubes intersecting each other, etc. and try to find the center of gravity of the whole tube-construction it may not even be in one of the tubes... it will not work for more complex structures but only for very simple once. I thought about it for quite some time now, and there is not really a better solution I can think of. Yes it can be overcome by good modeling practice, but I think I am quite able to model in a good way and understand more or less what I do, but even with all that years of modelling experience sometimes I run into trouble with normals if I try to model fast without thinking too much about it and just having a little bit of fun till it turns out to be something nice I want to go on with...

Bingo Nancy... it is really just about the normals pointing the right way. Seffen tried several ways to implement an algorithm to get that job done ("Correct Normals"-Plugin, Refind-Normals, etc.) but it never works perfectly for me in more complex situations. And I think this plugin should do the job. And yes, some features need correct normals... hair, 5-pointers and all the exporters, especially for 3d-printing-stuff it is quite important. See you *Fuchur*

You have to get in touch with Jason for that. (> support@hash.com). You can make it a little faster if you use the host-id-tool (for instance available at the trial request-page) and get the host-id and let it determine the host-id of your new computer and send that to Jason too. I'd say you will need the new host-id, your subscription-key and if available the old master0.lic-file. (if that is not available, it should work without too... Jason will tell you what to do then. See you *Fuchur*

My most wanted: - an FBX-Exporter / Importer. - a plugin, which will set normals by placing a light inside a model, on the light and open the Plugin. After a setting dialog (bounce-time, distances?) the rays of the light will now hit the patches from "inside". Anywhere where a light hits a patch, the patches normal will flip to the inverted direction of the light ray which it has been hit from. The "light ray" should than be killed or even better: bounce of and do the same again for a setable amount of bounces. Should only be done to "visible" patches. (so if you hide something, it should not be affected) Just to mention it: It does not have to be a light of course... if a null or a point of a spline is easier to do, that is as good as a light too . See you *Fuchur*

The problem I see is that, you are using no 5-point-patches but instead a star-intersection (more then two splines crossing in a point between the fingers). That will result in the hard edges there... Have a look at my tutorial here... it is about a foot, but in the end, it is the same... . http://www.patchwork3d.de/erstellung-eines-fusses-181-de around 6:00min it starts to get interesting.

I'll follow this . Very interesting workflow. See you *Fuchur*

Why? Win8 was bad, Win 8.1 was a little better and I think Win 10 is good again. See you *Fuchur*

You will need eighter 2 groups to do what you want or you need a higher density of patches / CPs in your model. There is no way around that. This is the problem with a "one-selection-mode"-approach, but I have to say I like the simplicity of that much more than I dislike the disadvantages and you will very fast yourself acustom to that and think in the "right" way when modeling stuff like that. In other software, you often can select many different things like vertex (cps), edges (a single spline) and polygones (a patch) by itself, but that makes stuff much more complex and you will often need to switch modes while working and you will often wonder why a certain tool is not available till you release, that you need to select the stuff in a different mode to get the tool you are looking for... if you are used to the "just select something and think about it later"-approach, that can be quite frustrating too... See you *Fuchur*

It will be fun . Exploring really is what it is all about . Poses can be deleted fully by going to the User properties option on the model the pose is placed on. Rightclick on the posename there and delete it. That should get rid of it without any left overs. Deleting for instance the relationship itself under relationahips will not delete everything. (i think because you can do different stuff manually with relationships too...) See you *Fuchur*

I'll write a feature request for that, but in the mean-time: Why not use action-objects or just a chor to get the funcitonality you want? In general build stuff from different "models" is done in the chor, not in a modeling-window. The good thing about a core is, that it references stuff back... that means if you realise, that you need an additional feature on all of your referenced models, you'll get it by changing the original model instead of all the different itereations you are using in the chor. (just to mentin it: Robert did recommend the renaming, not me ) See you *Fuchur*

Very interesting! See you *Fuchur*

I am not sure if that should work or if it is already as it should be... (I assume it should work the way you try it....) But you can do the same with Euler-LImits-Constraints... I would create a pose-slider (on / off) for that, select the bone and right-click on it. Choose "New Constraint > Euler LImit" (or what Limit you want) and set it up using the degrees on the axis. After the model has been dropped to the core, open the pose-sliders-view and set it to on. (if you can't see it initially, click on the tab-group in the pose-slide-view... this is only necessary if you created a new pose after dropping the model to the core...) See you *Fuchur*

Did you install the "stuff"-file for the old version? Look for the file for your version here. > ftp://ftp.hash.com/pub/updates/windows/ Concerning the trial: Did you download the master0.lic-file and copied it to your installation folder? Is it really named "master0.lic" not "master0.lic.txt"? See you *Fuchur*

Hi Robert, it happened when I tried to add a group to the newly created folder... See you *Fuchur*

You can create a group-folder. To do that, right-click on the "Groups"-element and choose "New > Folder". This should get you the possibility to reselect them very fast... but I would not use that feature at the moment... it crash A:M for me when I tried it. Just go with the option Robert gave you. It is not hierachically but I am not sure why that would help... what are you trying to do? See you *Fuchur*

I am just guessing here, but please make sure that you have installed this file too: ftp://ftp.hash.com/pub/updates/windows/Am2005/v12stuff-full.exe For older versions the stuff-file needs to be installed additionally to the software itself. See you *Fuchur*