Off topic stuff moved from "Refining Our Direction at HiveWire 3D" thread

[kobaltkween]

I have posted on the Dawn renders thread about nVidia's powerful and FREE OptiX 6.5 GPU accelerated denoiser, where the results I've got were quite superior to what I could get from Blender denoiser. It's a self-contained program, so people can use it without having to install anything else. There is also a version that can be used with Blender as a 3rd party plugin. The only downside is that the standalone version has no interface, so it has to be ran from a command line. I was thinking on creating an interface for it. For the time being, I made a batch file where we can just drag and drop images over it, so we don't have to use the command line.

The filter is the IBM denoiser. It's better than both the _Cycles_ denoiser (not Blender, that also has the ability to use the nVidia one) and the nVidia one. And unfortunately the nVidia denoiser can only work with the right hardware _and_ right software. IIRC, the IBM denoiser only needs hardware newer than about 20 years ago. Works on AMD just fine. As for "self-contained," I don't see the issue. Either way, you have to install a new program. IMHO, the big thing is ease of use and results. And as shown in the video I linked to, the IBM denoiser generally performs best.

For a long time I have also thought the Morphing Tool couldn't grab and move geometry around, but it actually can. From the "pull" or "push" brushes, select the "Screen" mode, and now you can move verts anywhere in relation to the camera. This is what I have used to create all of my Body Type series sculpts, without ever leaving Poser. I also use this to create all the necessary JCMs for pose correction. When we do things this way in Poser, and then save the results to the library (or export as morph injection), it preserves the geometry (remains unimesh), which is what we want.

I already knew about that, and tried it when it first came out. I've never found it useful at all, but to each their own. Thing is, though, it's still push and pull, not grab. It doesn't work at all the same. It's just quite limited compared to Blender's sculpting tools from 2.43. Blender's sculpting tools now are light years ahead.

I have zBrush, but I find myself using it very seldom nowadays, because the Morphing Tool allows me to keep posing the figure as I sculpt it, which is not possible with zBrush. Another reason I avoid zBrush for body sculpting from Poser is because I cannot export morph targets from either zBrush or Poser. If I do, the geometry will be split, and cannot be used in DS. If I do everything in Poser, like described above, I can save the results to the library or export morph injections without messing up with broken OBJs. If you want the morph in DS, just save to CR2 and load it back in DS. We can ignore all the weight maps error messages, since we only want the shape. Once this is done, export to OBJ from DS, and now we have a morph target that works in both programs (assuming you export in Poser scale).

In my personal experience, I have been having great results with this workflow.

You have to keep in mind that I've literally never seen any conforming clothing look natural to me. Not even the stuff that you can tell has like 100 dynamic simmed morphs in them. I _much_ prefer even skin tight clothes to be dynamic, to the point that I really think being able to set starting stretch/tension would really be useful so I didn't have to keep scaling down in the first frame. So I'm really the wrong person to make a particular JCM workflow case to. I'm pretty much at, "Just tell me what the standard is." That said, sure I find the stay in Poser and just use the Morphing Tool workflow easier. It just has much more awful (to my eyes) results than if I could use a better sculpting tool than the Morphing Tool. Which is just about any other sculpting tool. It just literally _cannot_ do certain things, and it shows.

Like Semicharm said, as soon as a figure is loaded into Poser, the mesh integrity is lost forever. This happens whether we export it or not, so the problem is not just with import/exports. I am reminded of this every time I create a JCM in Poser with the Morphing Tool, where we have to use the pre-pend/post-pend workaround before and after making any changes, or changing a pose. If we forget, the morph may be compromised and we have to start over. We wouldn't have to do this if the mesh was preserved as unimesh after loaded. The Morphing Tool expects meshes to be unimesh, but Poser doesn't support that internally, and that's why the workaround was introduced. Without that, the Morphing Tool would have a good chance of exploding your model when making JCMs. Happened to me a few times, and can keep us from finishing a product. The workaround works, but it's still a nuisance.

So you're absolutely right - the Poser creators have to take a hint from this. LadyLittleFox wrote an article about this, even claiming it was a major reason why she gave up on Poser, because she couldn't finish her products with P10 (the workaround was only introduced in P11 SR-5). This is a serious issue that does affect content creators. Unfortunately, SMS told me this would require rewriting the Poser core from scratch, so it's not something that could be "fixed", but instead something that would have to be "changed" deep inside the way Poser works.

In a way, for those who are old enough to know, Poser was never designed to do the things it does nowadays. It kept growing and expanding over time, attempting to accomplish more in every version. But the core functionality was designed to split the geometry in every part of the process, and that has never changed. So it's not that Poser is "broken", but instead that it was designed to behave like this because, by that time, it sounded like a good idea. DS wouldn't exist until a decade later, so by then we didn't need "unimesh" support to make products work in both programs. As a matter of fact, all of Autodesk's mainstream 3D programs do not support unimesh to this day. If we create a figure grouping in, say, 3DSMAX or Maya, it will split the model just like Poser does. There are actually very FEW programs that support unimesh, namely Blender3D, Modo, and [maybe] Lightwave.

I could only hope Rendo will address this in Poser 12, but I wouldn't hold my breath for it. I doubt they would try something this deep at this point. I don't know who's in the dev team now, but it would require changing the Poser internals quite significantly, according to what Larry Weinberg told me back in the SMS days, just before they would start working on Poser 12. Nonetheless, it doesn't hurt to be hopeful.

This is why I prefer the Morphing Tool to create my JCMs - it doesn't require any OBJ exporting/importing, and hence avoids the non-unimesh issue. The pre/post-pending workaround is still a nuisance, but it works. The GoZ workflow also works, but we can't change poses in zBrush to test the JCM for different bending angles. To me that's the big plus of using the Morphing Tool to create JCMs. Or perhaps, especially when creating JCMs, because we have to test and make adjustments at different poses.

I think that the information you have might be incorrect in terms of what is possible. Having pursued this previously, and worked on various issues around it that are similar, what you're saying kind of makes no sense if you stop and think about it. What you are saying is that _exactly the same mesh_ with different vertex orders can't possibly be parsed. Because whether you're splitting or welding, you're going to end up with the same positions and vertex count regardless, right? Sort of like if I made two identical meshes by hand.

Not only did I try a script that actually was supposed to fix differences in vertex order (I didn't get it to work, but I can't promise that wasn't user error), but this is similar to the problem of transferring morphs from figures to clothes. A problem which was solved ages ago

So your whole presumption that once a mesh changes its state from welded to split, it is irrevocably changed, that you can't go back and forth, just doesn't make sense. There's too many tools that transfer shape to totally different meshes. Not to mention, I think if we can build AI, someone can write an algorithm to go through a mesh vertex by vertex, see if a relative vertex position matches a vertex in the target mesh, and if it does, give it the vertex number of the found vertex. Might be inefficient, but that's all you'd need to do.

If we start from Poser, we can only create JCMs in programs that support unimesh, which includes Blender and Modo. However, the problem is that we CANNOT export any rigged figures from Poser, because the geometry was broken the moment it was loaded into Poser. Therefore we are left with either GoZ or the Morphing Tool. Even if we use GoZ, the geometry will still be split and broken, so even if we export morphs from zBrush to OBJ, it will also be broken (vertex count won't match the original). Poser can still handle this (with a few exceptions), but none of these OBJs will work in DS.


On the DS side, they didn't fix the non-unimesh problem just at import/export level. DS never splits the geometry. It is always unimesh at all levels, just like Modo and Blender do. If Rendo would resolve this in Poser, that's how it would have to be. It wouldn't be a "fix", but instead a "change" in how it works internally. When the Morphing Tool was first introduced, it was meant to work with unimesh geometry, and that's why the workaround was introduced in P11, because it couldn't handle JCMs in P10. If we pose the figure and try to sculpt on it with the Morphing Tool without changing the transforms order first, the vertexes at the borders between groups will spike out. Even if we first convert the model to Unimesh Skinning, it will still spike out when we return to normal skinning mode. That's how bad it is, so we have to use the workaround until Poser stops splitting the groups.

SMS claimed I was the first one to ever report this issue. I am pretty sure other content creators knew about it, but if they don't report it, there is little chance it will ever be addressed.

Again, we already have a way to transfer morphs among similar shapes. And again, all a program would have to do is:

Count all vertices in two meshes to make sure they have the same count
Make a hash of the target meshes vertices, their position, and their order number.
Go through the subject mesh vertex by vertex, get its position, find the target vertex with the right position, and give it that target's order number.

Might be slow, but that's a pretty simple set of steps.

But sure, if they don't want to bother with thinking creatively, it's not going to happen.

 

[Ken1171]

the IBM denoiser generally performs best.

Like you said, to each their own. It's good to have options, and I prefer the OptiX AI-Denoiser because it preserves small details and large flat colors better than Cycles denoiser, and hardware accelerated AI makes it almost real-time (great for animation!). I am trying to impose - just showing the option is there for those who want it. This week Reallusion has announced that CC3 and iClone will have OptiX integrated into their real-time PBR rendering pipeline. Besides the quality and speed, it's easy to adopt because it's free and open-source, which means even Poser could adopt it.

It's just quite limited compared to Blender's sculpting tools from 2.43. Blender's sculpting tools now are light years ahead.

I have no doubt Blender and zBrush are better better than this little Poser trinket - I am just happy to have it when Poser has issues exporting things.

I think that the information you have might be incorrect in terms of what is possible.

Maybe there is a way to put the geometry back together in the same vertex order, but if so, nobody had done it this far. Maybe it could be solved with a vertex map profile for each figure, assuming the vertex order wouldn't be random every time. During the import/export process, the vertex order would be changed TWICE - once when imported (and split), and then again when exported (and welded back together). At this point, attempting to restore the vertex order would be quite a challenge, because it could have been totally randomized twice. In that case, the original vertex map profile would be useless. Semicharm has done some work recovering vertex order with some success, so at least I know some of it is possible. Not sure about the whole thing, though. Semicharm told me that would be impossible.

Again, we already have a way to transfer morphs among similar shapes.

Considering the mesh would have its vertexes reordered when first split, and then again when welded back together, how would you FIND the corresponding vertex in the OBJ file afterwards? That would be the first step to resolve this issue, and perhaps the most critical.

 

[kobaltkween]

Like you said, to each their own. It's good to have options, and I prefer the OptiX AI-Denoiser because it preserves small details and large flat colors better than Cycles denoiser, and hardware accelerated AI makes it almost real-time (great for animation!). I am trying to impose - just showing the option is there for those who want it. This week Reallusion has announced that CC3 and iClone will have OptiX integrated into their real-time PBR rendering pipeline. Besides the quality and speed, it's easy to adopt because it's free and open-source, which means even Poser could adopt it.

Again, the _Intel_ denoiser is totally different than the _Cycles_ denoiser. To be very clear, the Cycles denoiser is _not_ a filter, and I don't think you can use it on anything but a Cycles render. Also, the Intel denoiser is free and open source, which is how it came to be added to Blender. You do not need Blender to use it, but AFAIK, Blender's the easiest solution with a GUI. I don't think anyone's made a standalone interface for it, but it's out there as code and such. I didn't pay that kind of attention to it, because by the time people were talking about it, the nVidia denoiser, and the Cycles denoiser, Blender had an add-on for the nVidia tool and 2.81 was due out in a week or so with the Intel one. But it's definitely an independent open source effort.

It performed better than the nVidia denoiser at small details and flat colors in the tests I've seen, and seems to be great at animation. And again, it works on all systems, not just ones with nVidia cards _and_ the latest OSs, which is true of the nVidia one. So if Poser incorporated the nVidia denoiser, they'd probably piss off about half their customers as it failed to work for them.

But if the nVidia software works for you, absolutely great. I certainly get that each of the denoisers are better and worse at different types of scenes and animations. Just be clear that if you've only tried the _Cycles_ denoiser, you haven't at all seen what the _Intel_ denoiser does in Blender. Totally different.

Just as a by the by, Blender renders also allow you to generate specific denoising data to help (albedo color, normals, etc.). I want to say that tests showed that this mostly helped, but sometimes didn't, but I haven't had that kind of problem with it to worry.

I have no doubt Blender and zBrush are better better than this little Poser trinket - I am just happy to have it when Poser has issues exporting things.

Oh, me too! In fact, I think if the Poser developers just added "grab," that would go a long way towards making me feel more comfortable using it exclusively.

Maybe there is a way to put the geometry back together in the same vertex order, but if so, nobody had done it this far. Maybe it could be solved with a vertex map profile for each figure, assuming the vertex order wouldn't be random every time. During the import/export process, the vertex order would be changed TWICE - once when imported (and split), and then again when exported (and welded back together). At this point, attempting to restore the vertex order would be quite a challenge, because it could have been totally randomized twice. In that case, the original vertex map profile would be useless. Semicharm has done some work recovering vertex order with some success, so at least I know some of it is possible. Not sure about the whole thing, though. Semicharm told me that would be impossible.



Considering the mesh would have its vertexes reordered when first split, and then again when welded back together, how would you FIND the corresponding vertex in the OBJ file afterwards? That would be the first step to resolve this issue, and perhaps the most critical.

It wouldn't matter how many times you randomized the order. Once the order is changed, it's changed.

Let's just talk about an unchanged figure in the sense that it's not transformed (rotated, translated, etc.) or morphed in any way. Just split, then welded. If you look at the obj file in a text editor, it's got vertex order and vertex position in a list.

Brute force is really dead simple.

1. Make a hash, associated array, whatever data structure will be quickest to search through of your target or source obj's vertex positions and orders.
2. Remove any double vertices in your newly generated obj, just to clean up and avoid problems
3. Make sure that each obj has the same number of vertices. If not, this isn't going to work. But given what Poser's done in terms of splitting and welding, none of this should be a problem.
4. For each vertex in your newly generated obj
5. Get the vertex position
6. Find the vertex with the same position in the hash
7. Get the order number of said hash vertex
8. Set the generated vertex order number to the hash vertex order number
9. Ideally, somehow eliminate the matched vertex to make the hash smaller and eliminate it as a possible match

Now that's just my thoughts without having any good ideas about speed or whatnot. Nor taking into account vertices that have been moved for whatever reason. But since Poser is the one moving them, we should know how the vertex has been transformed and be able to relate it to its pre-transformation position. Which is all we'd need to figure out what vertex number it should have. But we're basically talking about two arrays of points with positions that should be constant and orders that are different. All we need to do is find the vertices with the same positions and give them the correct order numbers.

 

[Ken1171]

@kobaltkween I want to try the Intel denoiser too. The more options, the better. I was just a bit confused because you've mentioned an IBM denoiser, and now one from Intel. Was there a typo, or there are more than one? And by the way, I can create a user interface for it. I was thinking of making one for the nVidia one, but I have found it quicker to run as a batch file instead, because it can process a whole folder of renders at once.

I already have a working prototype for the OBJ fixer, and it was not as simple as it may seem. I have elaborated on the issues on the dedicated thread.

 

[kobaltkween]

@kobaltkween I want to try the Intel denoiser too. The more options, the better. I was just a bit confused because you've mentioned an IBM denoiser, and now one from Intel. Was there a typo, or there are more than one? And by the way, I can create a user interface for it. I was thinking of making one for the nVidia one, but I have found it quicker to run as a batch file instead, because it can process a whole folder of renders at once.

I already have a working prototype for the OBJ fixer, and it was not as simple as it may seem. I have elaborated on the issues on the dedicated thread.

Sorry, that's me not paying attention. It's Intel. IBM has nothing to do with it. I'm totally sober, so I've got no excuse.

I don't know where the code is, but I'd bet if you look up Intel AI denoiser you'll find something to work with if you want to build a GUI for it.

 

[Ken1171]

I have checked the Intel AI Denoiser, it has some good and bad sides. The bad is that it's still CPU-only, and it claims to require Intel-specific processor instruction sets such as SSE4 and AVX to accelerate the process. I have an old 4th generation Core i7 that doesn't support AVX, so I may not have the best performance, and AMD processor users may not have any acceleration at all. At least Intel claims they will include GPU acceleration at some undisclosed point in the future, so there is hope.

The good is that there is a version for Blender Cycles 2.81 that comes as a shader node - which has the potential to be incorporated into Poser Superfly!! Maybe by the time Rendo decides to update SF somewhere in the undisclosed future, the Intel AI denoiser for Cycles may already support GPU acceleration. ^____^

For the time being, I will use nVidia OptiX because I already know how to use it in Poser renders, and it's GPU accelerated. In my tests, with my existing hardware, nVidia OptiX has finished denoising in around 6 times faster than the Intel denoiser. Maybe that's because my CPU doesn't support AVX, who knows? Both produce great results, and over time the Intel one may catch up with performance when it starts supporting GPU acceleration. I hope it does, because competition will always benefit the end user - us!

 

[Carey]

Fan tails, I am hoping I live long enough to turn my city into all fan tails. There is just that little thing about them, see their show boats through and through. If it wasn't for that one little thing.....

 

[Rae134]

Those last 2 are very handsome

 

[Carey]

Those last 2 are very handsome

ah you should see them in the mating dance, to see them dancing on the peak of my roof, on the lawn, the wicker chairs, the glass patio tables, me lying in the lounge chair, they will even dance around your car tires in the drive way, the rest is R rated...lol

 

[Ken1171]

What?? No romantic dinner first?

 

[carmen indorato]

some compensations are more important than feeding your intended's face!
Beautiful birds, never seen one.