I couldn't edit above post, or at least find an edit button, so I am amending my post here...

I apologize, I meant to load up my workbox  for the actual VWD versions I am using before I hit submit post.

Version 1 with the Philemo bridges is : 1.1.522.3630

Version 2 with the native DS bridge is :  2.2.924.6464

@the_tdog :

It's never been a standalone thing.  Though, Gérald did once show an image in a thread with evidence that he was toying with the idea, because it had an OBJ import button, and I really wanted him to go in that direction, but several years have past and that did not happen.

Did you mean the native Poser plugin?

And, yes, VWD is a standalone EXE that one can open up and look around in, but without either bridging from within Poser, Daz Studio, or Carrara, it is just a useless empty shell.

So, with that out of the way, what exactly is your issue?

Exactly which version is not installing?

Exactly which version of which software is the bridge software not installing?

I am running VWD EXE version 1 (last iteration) with native Poser bridge in P9 and PP2014, version 1 (last iteration via Philemo bridge) in DS Pro 4.9 and Carrara Pro 8.5, and version 2 with DS native bridge in DS Pro 4.12 on Windows 7 PC.

What, if any, are the error pop-ups stating?

Maybe the 'host' software version you are trying to install the bridges to are unsupported.

Maybe the OS you are trying your installs with have UAC issues, or compatibility issues.

WIthout better details, it is hard to troubleshoot your issues...

titleknown :

Your import/export settings for both software are incorrect.

For morph target work you don't need most of those settings  --  You only need what is required for morph target work;  The facet and vertex data (technically, just vertex [delta changed] point cloud data, but with a caveat for Poser Legacy Figures).

And, while your work-flow worked for Genesis figures, you were just off by one setting in your Blender export to have it work for Poser Legacy Figures in Daz Studio.

Below is how to achieve a successfully applied morph on Dodger's Warforged in Daz Studio that was created in Blender.

I am using Daz Studio 4.12 and Blender 2.93, but the basic I/O settings for both software should be roughly the same.

* DS OBJ export settings;  Only select 'Ignore Visible Nodes', 'Write Faces', and 'Write Groups'.  *** Uncheck all other settings.

* Blender OBJ import settings;  Only select under 'Geometry' :  'Keep Vert Order' , and 'Poly Groups'.  *** Uncheck all other settings.

Create your morph, and then export.

* Blender OBJ export settings;  Only select under 'Geometry' : 'Keep Vert Order', and 'Polygroups' (this is what is needed for 1:1 mesh data transfer fidelity for the Poser Legacy Figures to work in DS -- Not needed with Genesis unimesh)  --  Also, if using Shape Key non-destructive morphing technique, you need to enable 'Apply Modifiers' for the morph deltas to be written to file (but take care not to have any other modifiers enabled in Blender [such as Sub-D] as they will apply as well)  --  And, lastly, under 'Include' : 'Selection Only' if there are any other objects in your scene.  *** Uncheck all other settings.

DS OBJ export settings:

Blender OBJ import settings:

Blender Shape Key non-destructive morph:

Blender OBJ export settings:

DS Morph Loader Pro import:

DS MLP import success:

DS successfully loaded morph applied:

*** As an aside; For the "No deltas for morph, skipping node." error  --  This was due to not having the polygroups designated to the facet data in the Blender export file (not needed with Genesis figures).

This can happen with Genesis meshes as well in use cases such as using the SK morphing technique and forgetting to set the Apply Modifiers flag.  There would be no changed deltas in the vertex data, and you would get the same error.

Hope this all helps.

Take care...

Ken

To switch gears here, Gérald, let's talk about the full VWD and the direction you are heading with it.

I have been sitting quietly on the sidelines just watching where you were taking it, and hoping you would implement things that would bring you a bigger audience (and more revenue).

You were very open in the beginning implementing some of my suggestions you thought were good, and rejecting others that did not fit your vision for VWD.

I had hope you would eventually work towards something that would yield more users/revenue, and it looks like your plan to open it up to more software might be the ticket.

I especially love that I might be able to use a future version with Blender -- It is part of my wishlist in fulfilling my Marvelous Designer clone with Blender and using VWD as my simulation engine.

So, this brings me to what I want to talk to you about possibly implementing in VWD (Pro, Standard), which is in line with your clothing product in this thread -- Working on implementing a cloth auto-retopo based on the Gmesh Advancing Front Isotropic Equilateral-Dominant Triangulation you use for your meshes which works best with your simulation engine. Correct me if I am wrong -- I am going off our previous mesh topology conversations, your inclusion of Gmesh retopo for volumetric closed manifold simulation (have not used yet, but have set my path to Gmesh), and your general affinity for Gmesh itself.

As you said, this control of the meshes will help in creating simulation standards based on mimicking cloth properties (cotton, wool, leather, etc.) which could help bring in more people as I believe this is something high on everyones wishlist.

I believe it could be done, but I am just going off my own workflow I use for dynamic remeshing in Blender which is comprised of multiple working parts.

I believe you could employ a similar workflow based from UV islands, separation, flattening, remesh-call (Gmesh), reconstitute flat patterns, vertex welds.

This is just speculation, and I can see it in my head, but outside of Blender, I don't know if you could employ all the working parts.

Without using Gmesh, the closest I can get to the Aline dress mesh is via Isotropic remesh in OpenFlipper. I haven't worked with Gmesh enough yet to know if this will work as I envision.

Thoughts?

Gérald, I downloaded and played a little with the Aline dress product (static sim only, so far) -- Here are my thoughts:

PROS:

• It feels like VWD (though, heavily crippled)
• Collision object import settings available
• Draping works fine (same as VWD complete product)
• Wind works fine (same as VWD complete)
• All the "live" sim settings work (Gravity, Inertia, etc. -- same as VWD complete)
• No issues with Start/Stop static sim for multiple re-sims per single session with Send To Host multiple times for morph target work (same as VWD complete)
• No issues with live deformation sim (though, only allowed on skirt)
• The view settings work with the cloth (color, wires, opacity -- same as VWD complete)
• Standard selections work (via shortcut keys only [shortcut key selection only NOT A PRO])
• Vertex locking/unlocking works (via shortcut keys only)

CONS:

• Auto-selection of cloth object (no user input)
• All import settings automatically set (no user input)
• Top half of cloth object locked to collision object with no way for user changes (no user input)
• No in-use parameter settings available (no user input/changes allowed)
• No view setting changes for collision object (color, wires, opacity)
• No select-by-material
• No custom selections
• No live deformation usage with top of cloth object (locked to collision object)
• No cloth shrink available for cloth object (collar strap/breast straps in desperate need of it)
• If not for already knowing the shortcuts -- No visual way to indicate to NEW users a way to lock/unlock vertices from simulation, nor how to engage selections

Now, these are more just based on personal taste of an experienced, advanced technical user, but I tried to put my mindset that of a newbie purchasing the product and having a play -- Just pushing buttons and see what happens (I know I cheated - I already knew the expected results).

I see what you are trying to do with this, but I think there are a few shortcomings for ease of use for newbies just purchasing for a quick sim with the cloth object.

• Pick collision object -- Check
• What to do next? -- Not sure (no indication cloth object is automatically selected/imported - just no more options) -- Press the Scene Viewer header to go to full screen of VWD -- No, just collision object in scene -- Press the Scene Viewer header again to go back to docked view.
• Eventually press the Simulate header -- Ahhh... that's it -- The cloth auto-imported and simulation auto-started.

I would put the cloth object auto-selected/imported and simulation auto-start in the PRO category, but it was too much of a guessing game just to get started, and I am a seasoned veteran -- Imagine a newbie purchasing not knowing what to do. You need to make the workflow very clear from the start.

Maybe, change it from having to press the Simulate header to an actual Cloth button like the Collision button (which auto-engages the Simulate header, go full-screen, and starts the sim as you have it)

Other than a not so clear start up, it is fine, but personally, I don't like it as a product. I believe the tool should not be included in the cloth product, and you should find another way to implement your auto-simple/non-pro quick sim clothing product to work with the already purchased tool.

Imagine you have 10 different cloth objects for sale and I purchase all 10 -- Now, I have 9 extra versions of the same crippled VWD to dispose of...

I like your idea for those who don't want/need full control, and just want a quick sim, but I think it should fall on the tool purchase side, and not the clothing side.

So, You already have the full VWD (let's call Pro), and a non-animation VWD version (let's call Standard). Maybe you should create a third VWD (this version in the cloth product), and call it something like Hobbyist or Quick Sim version. And, you can decide to make it free/available only for those who purchase a clothing product for it's use.

This is just a guess, but since this is the second time I have seen that UI setup in the past month or two, my guess would be it is the custom UI of the person who he downloaded and is loading whatever the free Blend file was (can't remember, but I downloaded it to check out) without unchecking the load UI checkbox.

It's not a virus or anything to do with downloading/installing -- He just keeps overwriting his UI on every load.

I remember that header, because my first thought was why would you name one of your scene tabs 'Hacker'? -- Maybe a rename of the Scripting Tab because he likes to hack the files...

Like I said, this is just a guess, and I could be way off, but it something you guys did not consider in trying to help out VolcanicMink with this issue.

Hope this helps -- If not, please disregard.

It's all good, Gérald/Dan -- I was just trying to help troubleshoot SimonJM's out of memory issue.

I never even noticed version 1 wasn't LAA as I never have had any issues regarding memory consumption.

As far as creating a LAA version, I'm not sure it is necessary, but it couldn't hurt. Also, good idea to maybe help those who don't know how to do this to be included in the manual for those who wish to utilize it (if you don't go with an already LAA version).

I was just curious if Gérald was able to circumvent x86 convention by addressing to RAM by way of some sophisticated PAE running in parallel, somehow quadrifying RAM usage for VWD. I have always been very impressed with Gérald's work, but this would have been truly magical...

Tested animated draping with the included Genesis 8 Female scene - Everything is working great, and, Gérald, that animation is hilarious. I want to try it next with your custom breast dynamic morphs.

• Upgrade purchased ! -- I hope you guys get many more sales, and continue to push VWD even better into the future - Keep up the great work!

Take care...

Ken

So, going over the install specs, and touching on SimonJM's question/issue, and from what I know regarding x86 software :

Why are the suggested RAM specs 8G (min.) and 16 - 32G ('good' mid-range) when x86 programs can only utilize up to 4G (if LAA) max?

The CPU simulation runs via cores, and I am guessing the GPU does the same (Cuda cores?). So isn't the base RAM only for springs storage along with object files in memory?

Is VWD somehow utilizing RAM beyond the x86 4G cap?

Gérald/Dan :

Just wanted to report that my nVidia GeForce GTX 650 (2048MB RAM) is working fine with ver2 demo so far with static drape testing. Still need to test animated drapes, but it looks like minimum requirements can be below the recommended 700 series.

Also, just an FYI - you have two script folders for install - 'ver2 demo' and 'ver2.x' -- The DSE scripts in the demo folder (which I believed should be installed) do not work - just unspecified 'failed to start' error, look in Log File, which just states script 'failed to start'.

The scripts in the 'ver2.x' work, but this might be confusing to newcomers wishing to try the demo -- As I am not a newbie at this, I knew the avenues to pursue to get a working version (first used the beta DSA scripts), but I would not have installed the 'ver2.x' folder where I believed this would be for when I purchased the upgrade -- Using the demo, I only would install the demo folder...

SimonJM :

The DLL is only to work with the correct running version of DS, but yes, the program is 32-bit, so no matter how much RAM you have you will never use more than 2 Gigs RAM for this x86 program - It is not Large Address Aware, so is capped at 2 Gigs.

However, I just tested (ver2 demo EXE) making the program LAA which gives the maximum x86 cap to 4 Gigs RAM on a x64 system. I only tested the included plane/sphere testing scene to confirm making the program LAA works or not.

I used Large Address Aware-2.0.4 to enable the LAA.

Now, this is old from pre-GPU days, and is in regards to CPU usage - I am not sure how this affects GPU usage, or if springs are only being stored in general RAM, which is where the cap comes in. Gérald will have to confirm the differences/usage allowances.

My suggestion would be to make it LAA, re-run your animated sim, and see if you still get the out of memory error on springs creation. Using 'Spring reduction' (check box) in Scene Import Tab often helps as well.

• EDIT: I know you said it gets to 800MB in corner, but from what I remember testing/using version 1, there is initial spring creation, and then compounded spring creation depending on different settings enabled - you might only see the initial springs creation reported, and the out of memory error due to further springs creation for the animated drape -- Corrections for this, Gérald/Dan - I could be wrong.

I tried editing my previous post, but it does not seem to have taken -- If this ends up a duplicate, I apologize.

Please disregard previous post - it was a SeaMonkey browser issue (can't see forum images), but I forgot I also have Firefox installed, and I can see images in FF just fine.

Great images and techniques everyone...

Hey all, quick, dumb question...

Are there any images in this thread?

I can't seem to see any images in this thread (haven't tried others). I thought it was a not logged-in issue, but logging-in yields same results. I checked my site settings, and can't find anything that would hinder me from seeing images.

I see images in the market, freestuff, and galleries - it appears I just can't see any here.

I don't believe it is a browser issue, but I am using SeaMonkey (Linux Firefox derivative) 2.48 on FatDog64 (Ubuntu based Puppy Linux).

Any help, or insight appreciated.

Okay, I'm back after testing, and fixing the export script for my use.

Sharing is caring - so, if you don't want to wait for a release fix, here is the fixed OBJ export panel : Fixed OBJ Export to include Polygroups

• Instructions included for manual install (not set up for ZIP install within addons preferences panel - though may work, but simple manual install - look at instructions text file)

I tested with a V4 figure, but only reading exported OBJ code (no Daz Studio import) - Polygroups included correctly in OBJ file...

SilentWinter/Lobo :

Yeah, it looks like it is an oversight/possible bug -- It is still listed as a flag in B2.81 Python API, so the boolean toggle can still be used, but is not exposed.

OBJ Polygroups flag : use_vertex_groups (boolean, (optional)) – Polygroups

So, for my custom export scripts where I have the flag enabled, it should work (all automated - not user selected). I just downloaded 2.81, and will look at the OBJ export code for confirmation - will report back later...

I need it for my work with Daz Studio as well, so you had me worried for a moment -- You just need it exposed on your end for usage.

As a work-around for now if you want to work in 2.81, complete your work in 2.81, open up 2.80, select and copy your figure in 2.81, paste your figure into 2.80, and then export as usual. It's faster than the writing seems - I do this with 2.80 and 2.79 where my custom scripts reside until I get around to upgrading the code to 2.8x structuring. I usually have them both open at same time.

KarinaKiev :

I am getting "Fichier inexistant." (File not found.) on your download page. Tried consecutive times to make sure first time wasn't a fluke...