ACV Burn Kopen - ACV Burn Keto Ervaringen Recensies & Belgie Prijs



  • ACV Burn België ervaringen - ACV Burn Keto-dieet pillen is een enorm populair koolhydraatarm dieet waar velen enthousiast over zijn. zie prijs, hoe werkt het, oplichting, bijwerkingen en waar te kopen. Als je denkt dat de verkopers geen oprechte mening hebben, en wat ze ook zeggen, bevooroordeeld zal zijn, dan heb je het niet mis. Maar laat deze veronderstelling niet leiden tot uw beslissing om ACV Burn te kopen. En niets is beter dan hiervoor ACV Burn te gebruiken, omdat het iets is dat de beste resultaten zal laten zien en er ook voor zorgt dat u helemaal geen nadelige gevolgen ondervindt. http://supplementenbelgie.be/acv-burn-keto/



  • DAZ Studio exports MDD, but I wasn't able to do much with it in Modo…but I didn't try to export animations, which probably defeats the purpose. I might do an experiment tomorrow with a simple 12 frame animation to see how it works.



  • @'Nuke':

    Cache, not cash.

    But still, with every software handling figure rigging differently, there really needs to be at least one rigging standard that a given format plugin converts to and from within each application that can use that plugin. Daz Studio and Poser are drifting apart as far as what type of figure rigging they use, Max has its own preferred format, and I'm sure TrueSpace has a completely different format. There needs to be a plugin that forces a universal skeletal system, and that carries with it a specific set of commands for the posing of a figure in any app that can read the plugin.

    The accepted/adopted rig/animation interchange standard is the FBX file. It already does exactly what you are suggesting

    But there are limitations. This isn’t down to the FBX but to do with the complexity of the task (animating deformations) and the different ways it has been implemented in various bits of software.

    e.g. exporting FK animation on a set of bones FBX will translate it beautifully as baked, key-framed rotations that can be read and translated by all. The problems come when you want the more complex stuff such as the way a bone deforms the mesh around it.

    Every single 3d software uses a different method and technique to deform a mesh (particularly at a joint) what you see in one software is going to be different in another at the joints.

    e.g. some software use joint compensation algorithms to inflate the edges of a joint to prevent pinching at an elbow or knee. Some of these algorithms use a constant volume technique others use a resistance model. Neither of these algorithms can be translated into data that could be either stored in an FBX or understood by another bit of software. As they are a core part of the program and its animation paradigm.

    Now lets think about IK. What’s the betting that two bits of software use the same solvers for IK? Or provide the user with the same level of control over the implementation within the software. There is no guarantee that a leg/arm bend in one bit of software will be the same in another unless both bits of software use identical IK solvers with the same set of resistances along the bone chain with the same set of parameters exposed to the user.

    You can get a rig, a set of controllers and IK goals all carrying animation between all the main bits of 3d software. These elements work just fine. What wont work properly is the deformations on the geometry. It will require user input to manually fix the propriety techniques used in one software to the propriety methods used in the other (if there is even an option to to do that within the target software).



  • Again, apologies for the length.

    Mdd's are a file format from an animation plugin called Motion Designer that used to be available for Lightwave (hence the file name mdd, Motion Designer Data). I believe it eventually was absorbed into Lightwave. However the file format was made open source (yay) so it can be used as a bridge between any 3d app that wants to write reader/writers using it.

    Point Oven is a 3rd party app that creates mdd files for Lightwave from within other apps like XSI, Max and Maya. It ships with its own reader plugins for Lightwave (and other software) but tbh the Lightwave native ones work just fine and with a bit of messing about you can "fix" any scaling miss-matches between apps.

    eg XSI → Lightwave is 10 times too big, so parent all your mdd objects to a null, set the mdd to local displacement and scale the null to 0.1, all fixed. If you wanted to be neat you could write the scaled mdd's back out from within Lightwave to operate more robustly and make any subsequent deformation change you want to make work at the scale your working at.

    The purchased version of Point Oven has a scaling switch built into the XSI interface but the native version that ships with XSI doesn’t, although you could script an exporter to scale your animation before export, sometimes the hassle this involves with the order of precedence and some rigging elements can make it a simpler task to fix scale in the target software. Unless you are comfortable scripting as you'd have to perform a bunch of cashing and baking operations before scene scaling and export.

    Modo has pretty robust mdd tools as the programs creator was one of the original programmers for Lightwave, as such those two apps have very good communication (with the usual provisos concerning texturing).

    Maya and Max have their own point cashing files. Max one is called a PC2's. Maya's native one is called MCC. These are essentially the same thing as mdd's but under a different brand name. I haven’t looked at the files to see if I can translate them from one to the other but the type of data held in there would imply it should be pretty straight forward. At least for the basic stuff such as a point index and an x,y,z coordinate. Lightwave has PC2 and MCC readers and writers (native) and I would expect that Maya has mdd readers (native) too. I don't know about Max.

    This essentially leaves you with only one problem. Exporting an mdd and an OBJ file to apply the mdd to. A google search for “mdd plugin” gives a lot of threads for mdd support in all the major 3d software including Daz and Poser. Though it may be that you have to buy a plugin from some 3rd party to export the data. I’m sure it wont be long till someone writes a free python script. Maybe if I find some time to explore Posers script support I’ll have a look.



  • Just discovered a little something which might be helpful for other 3D programs which are neither Daz nor Poser… Apologies in advance to anyone else here who might have already known of it. I know not 100% related but, slightly if you were looking for some stuff to use in the meantime.

    https://shop.3dtotal.com/



  • Cache, not cash.

    But still, with every software handling figure rigging differently, there really needs to be at least one rigging standard that a given format plugin converts to and from within each application that can use that plugin. Daz Studio and Poser are drifting apart as far as what type of figure rigging they use, Max has its own preferred format, and I'm sure TrueSpace has a completely different format. There needs to be a plugin that forces a universal skeletal system, and that carries with it a specific set of commands for the posing of a figure in any app that can read the plugin.



  • @'nyaid':

    Appologies for the length of the post.

    Thanks for the length of the post. That was great information. Are there multiple point cash solutions, or is Point Oven THE solution for this?



  • Appologies for the length of the post.

    The problem with transferring rigs between applications is that the different software systems all work in slightly different ways and some of those differences wont translate correctly from one application to another. The FBX system was created to make a standardized platform to allow data interchange between multiple softwares within a predefined limited set of industry standardized elements. So you ought to at least be able to get a mesh, a set of bones and set of bone weights between softwares assuming that both bits of software address the FBX format correctly.

    The real problem comes with the subtlety of deformation under bending (posing). Although the FBX can hold Maya Blend shapes you will still in all likelihood have to hook them back up buy hand particularly if they are driven by the rotation values of your bones as opposed to a key-framed slider.

    Surfacing:- If your objects only apply surface data via an image map and a UV coordinate then you are set. If however you are using procedural, nodal or proprietary surfacing information this will all have to be redone in the target softwares proprietary surfacing methods.

    OBJ format. An OBJ is a single mesh with a single UV (if your software can make multiple UV's these have to be combined into a single map upon export) It can support part names (this is how to apply your surfaces) however it can be very fussy with its part naming (NO WHITESPACE) and it can be very intolerant of some types of geometry. (Remove all single verts and 2pt polys and triple all n-gons) it is also advisable to weld all overlapping points together into a so called water tight mesh {you'll know why when you get creative with a pose and see splits in the mesh}).

    Because of this lack of control for all your morphs your best bet to accurately export your pose is to freeze the mesh and get it out as an OBJ then fix the texturing. If you have animation or lots of poses within a single scene you could either try and bake out the poses as a series of morph targets (Maya blend shapes) and transition to them in your target software or if you have a lot of poses or animation a better work flow is to use a point cash. The advantage of a point cash is that it will give you exactly what you have done in your starting software into your target application both as a single pose or as a frame by frame animation. The disadvantage is that you have very little ability to further modify the shapes in your target software.

    A point cash bakes out the co-ordinates of every point in your mesh for every fame, so the files it generates can be quite large if your models are heavy and you have a lot of frames. Your target software will then linearly interpolate between these bakes on a frame by frame basis. You only need to export your character the once and then you can apply countless mdd's to it. The only proviso is that the target mesh has to have the same number of points (with the same order, so some remodeling modeling operations need to be avoided eg cut/paste) in order for the cash to work as expected. You can subdivide the target mesh but only after the cash has been applied.

    Point Oven is a popular system for getting animation between Softimage, Lightwave and Modo for instance or anything else that can read an *.mdd



  • I thought about writing a script, but it seemed like more work than it would save, since I have my materials as presets. But I'd love to see a script that transfers rigs properly.

    My last render (http://affect3d.com/forum/showthread.php?tid=4417) used procedural textures for the background and the swimsuit, which was a lot of fun to play with. I'm leaning towards upgrading to 801 for that, plus making my hair in-app (although hair is hard), and dynamics. Lots of tools to learn and play with. But how much better it would all be with some scripts to get the rigging and textures in better!



  • @'LoChrome':

    At this point, though, my biggest annoyance it not being able to export or import so geo that shares a map has a single texture. Importing a corrected OBJ requires me to select Head, Neck, Torso, Nipples, and Hips for the Torso group, then the components of every other group to assign them a single material. But I like my results, so—at least as long as my 30 day trial persists, I'm going to keep at it.

    Yeah, that's a bummer in general I've seen with Blender too. I'm going to go with scripting (or some kind of automation) again. Haha.

    When I was leaning toward using Blender I started writing a custom add-on to import material and textures from a .duf file (but read geometry from the .obj file) to workaround this. It was the intended beginnings of a DSON importer. It worked well enough to prove I could do it but then I lost time my spare time.

    If/when I get into MODO enough to upgrade from indie to the proper license (or they add scripting support in indie), I'd investigate doing the same or continuing that work in MODO. Since a number of 3D packages support Python I have grandiose ideas of writing DSON importers (not including TriAx weighting). Alas I don't have the spare money or time…

    There were some existing scripts to ease working in DS and rendering in Blender, but I'm too new to MODO to know if any exist already.



  • @'Nuke':

    If that's not the case, and OBJ is getting the job done just as well, this info needs to be spread around so people stop wasting time and money on programs expecting these features, or Daz and Smith-Micro need to get their ass in gear and build a fully-functional exporter that includes rigging.

    Not sure this is entirely on DAZ or SmithMicro, but it would be cool if they were able to solve it. I don't think FBX or Collada have support for defining control rigs to be exchanged between apps. So this is an issue with any FBX or Collada file, not just those from Poser/DS. In my mind this can't be solved by an exchange format. Or at least no current exchange formats.

    MakeHuman solves this for Blender by exporting a Rigify rig. You could see SM or DAZ doing something to support the destination apps auto-rig for a control rig. Actually maybe you can't and that's more of a third party writing a script in the destination app :P. Doesn't solve the TriAx or JCM issue if that is your need.

    @hzr:

    …export as OBJ in static poses, and then render these out, then export the next static pose from DS/Poser etc. The second way is what I do for example, and it can be very tedious, especially when you are making mistakes, exporting the wrong poses etc, since you will have to re-export again, overriding any changes you may have made to the meshes before that.

    This sounds like a prime candidate for scripting or vertex cache?

    Looks like DAZ Studio can export .mdd. Does anyone know if this is a point oven file or something else?

    I saw a video where Alembic was used to bake animation from Maya and then import into Modo where they did look dev/texture/render. This (naively) seems like a potential workflow; poses are stored as key frames, baked out as animation and then rendered to images?

    I've admittedly never done it, but this was a workflow I toyed around in my head if I were going to pose in DS.



  • I'd love to see more robust exporters. FBX gives me pretty unusable results—everybody back to the T pose, with the skeletons sitting unattached to the geometry. Exporting with figures in T pose gives me attached geometry, but its badly skinned.

    At this point, though, my biggest annoyance it not being able to export or import so geo that shares a map has a single texture. Importing a corrected OBJ requires me to select Head, Neck, Torso, Nipples, and Hips for the Torso group, then the components of every other group to assign them a single material. But I like my results, so—at least as long as my 30 day trial persists, I'm going to keep at it.



  • Another little quirk of Genesis 2 figures involves the SubD not following the pose when you export in certain formats, even with the Fusion plugin. You end up with your posed figure and the SubD figure in t-pose, and the meshes are counted by Max as one figure, so separating them involves mesh surgery.

    It makes absolutely no sense to me to have all these newer export options (FBX for Poser Game Dev, Collada for PP2014) if they're not including some sort of rigging. The FBX and Collada import functions of Max 2015 even asks about Bones, which I assume means it expects to find a rigged figure.

    If that's not the case, and OBJ is getting the job done just as well, this info needs to be spread around so people stop wasting time and money on programs expecting these features, or Daz and Smith-Micro need to get their ass in gear and build a fully-functional exporter that includes rigging.



  • Havent read every single post now, but if you plan on using G2 or other daz figures outside of it, and want to animate in that external application, you will have to know what you are doing. There is no make-perfect-rig button so to speak, and you will get some auto rigged figure with acceptable basic weights out of some applications, but this is absolutely no match for the bends that DS and Poser produce with the figures, due to different weight map techniques and custom jcm which applies correctional morphs to joints depending on the rotation angle of the joints.

    This will be your job after you have the basic fbx import done. Good luck :D

    The artists who are currently working with external applications around this forum and I would wager most of the 3dx scene are most likely using stuff like Poser Fusion, or simply export as OBJ in static poses, and then render these out, then export the next static pose from DS/Poser etc. The second way is what I do for example, and it can be very tedious, especially when you are making mistakes, exporting the wrong poses etc, since you will have to re-export again, overriding any changes you may have made to the meshes before that.



  • XNALara and Xna Posing Studio were part of a kit by Microsoft (both still free to download BTW) for homebrew game makers desirous of putting them on the PC windows and XBOX & XBOX360 platforms. These were specific to 3D, but I do believe they tried to cover 2D as well.

    You could rip assets from games and the like while also creating your own content and making your own game.

    While the project was up, I do believe they had representatives ready to help with copyright permissions if you wanted to take it beyond freeware/fanart games. However, they shut it down.

    Also, there is a metric shit ton of things on DeviantArt to be downloaded for XNA and XPS. Even game mods, matter of fact (IIRC someone gave Lilly Rochefort from Tekken a bikini model with bare feet using Victoria5). I do believe that's how other members here have gotten their own versions of Juliet Starling. I could be mistaken, though.



  • XNA is some sort of game format. For the Dragon Age head morphs I made for someone here recently, the files were in XNA/XPS format, and open in Max with a free plugin (XNALara - something to do with Tomb Raider). The thread had a link to all the extracted files.



  • Thanks. I've started using Modo 801 with .obj files, which loses the rigging. Fbx brings in the rigging, but its lousy—the geometry isn't mapped well once it goes through the export/import.

    What are XNA/XPS? Are those Poser exporters? If so, do they work well?



  • @'LoChrome':

    For people using C4D, Modo, Max, etc., when you bring in DAZ models and props, are you able to capture the rigging, texture maps, etc.? Or do you bring them in and recreate them?

    I have an old version of Modo and am thinking of upgrading, but if I have to redo all of the rigging, it becomes much less valuable to me.

    From what I know… I am speaking from how people use XNA/XPS to do the following, and those programs aren't too unlike Daz.

    One way is exporting as an object file or ".obj". This method requires that you have to rig it in in your desired program order to use it. Probably the crudest of all methods but it works where nothing else might. Otherwise you'd have to check compatibility of certain models/figures file types between the programs to be sure you can transfer more than that--sorry I'm still learning here so I can't help you with this.

    A slight modification of this method is the added step of transferring an .obj to a "middle-man" program. Basically one program which multiple 3d programs can recognize (like z-brush, etc.), work on it there to refine it and save it as a recognized file type before you put it into the 3D program of your choice.

    Hope that's helpful.



  • Totally agree with your views and certainly intend exploring these further within C4D.
    Converting mats should only take some time the first time round, for a particular character, but for subsequent poses will be a breeze and will be the basis for other characters as well.



  • After my first attempt to pull something from DS to Modo, I have mixed feelings. On the plus side, DS was chocking on the scene I exported to Modo and Modo ripped through it quickly without a problem. Modo has a lot of extra features that, if I take the time to learn them, will be a big win: a hair/fur system that should produce nicer—and more flexible—results than poly-based hair; a particle system for, um, fluids; I'm already thinking about using the particle system for a disappearing into sand kind of thing, too; and the built in modeling/sculpting tools are much more powerful than any kind of morphs in DAZ.

    However, I'm not convinced the renders are actually going to be better, given equal time learning both systems. Converting materials is seriously time consuming. And with pre-posed figures, the rigging was lost. I'm going to stick with it for the month of my Modo 801 trial and might upgrade. But it's not quite the obvious choice I'd have liked. (Particularly since I already have Modo 301 for modeling.)


Log in to reply
 

Looks like your connection to NodeBB was lost, please wait while we try to reconnect.