I'm extremely surprised to see that VWD bridge is not working with the latest iteration of Daz Studio... I don't want to use the latest D force thing.

So I had to go back to 4.9

I'm looking into it. Should be solved sometime next week

Philippe, if I can help for something, please tell me!

VirtualWorldDynamics posted at 1:10PM Sun, 29 October 2017 - #4316869

Philippe, if I can help for something, please tell me!

Yes please. Can you lend me your time machine? :-) Plenty of ongoing projects and a lot of work on my regular job (you know, the one paying the bills). I'll try to free up some time as soon as possible.

OK, Philippe, I can try to send you this machine, but it needs some debugging works to not arrive at the Neanderthal Time (100.000 years before DS). Even if this would resolve our problem.

OK. Studio 4.10 is installed. So far so good. First test with Genesis male 2 and Grantham jacket: It works, materials are there. No issue there, it renders fine. Save the scene. Close Studio. Restart Studio and load saved file. Materials are still there... and render works.

I'll do some more test but I'm afraid I'll need more information to solve the reported issue. The best would be a case involving only some product I don't have to buy , something shipped in with studio.

Every piece of clothing that I have converted, which has more than one surface, appears to lose its uv map and ends up with a single surface with some sort of borked uv map.

Edit: Actually it's more like the all surfaces and uvmaps merge into one. So if the object had multiple surfaces that all use the same image maps, then it looks fine. But if each original surface has it's own image map, then only the part of the combined surface which used the current image map looks ok, and the rest are all borked.

Also, it crashes daz a lot on exit.

Thank you for the feedback. I'll try to find in my library a cloth that fits the description and do some more tests.

Ok, it's a bug in studio: see this thread in daz forum

That appears to be slightly different.

When I export to obj, the object loses its image maps, but it still retains multiple surfaces.

When vwd converts, the object's surfaces merge into one, and retain the image map settings for the first surface.

Hello Philippe,

I believe it's related, and i'm not sure DAZ will consider it's a bug ? If i go to the exchange folder and import the objects created by VWD (or the bridge, i don't know), textures of the object are named "default". However, if i export the same object through the menu, i can see the textures if import the object again.

My guess would be that default export options are slightly different in Daz 4.10 and this might cause some compatibility issues with scripts. Maybe a workaround would be to force to export materials in VWD bridge scripts ?

Here is what can be seen in the log

2017-10-30 20:49:28.028 DEBUG: 968.029 - getting material for object B_Clothe
2017-10-30 20:49:28.028 DEBUG: 968.029 - adding material with id undefinedand name chest
2017-10-30 20:49:28.029 DEBUG: 968.029 - adding material with id undefinedand name neck
2017-10-30 20:49:28.029 DEBUG: 968.029 - adding material with id undefinedand name back
2017-10-30 20:49:28.029 DEBUG: 968.029 - adding material with id undefinedand name sides
2017-10-30 20:49:28.029 DEBUG: 968.029 - adding material with id undefinedand name pants
2017-10-30 20:49:28.029 DEBUG: 968.029 - getting material for object B_Clothe_VWD
2017-10-30 20:49:28.029 DEBUG: 968.029 - adding material with id undefinedand name default
2017-10-30 20:49:28.029 DEBUG: 968.029 - getting material for object B_Clothe_VWD
2017-10-30 20:49:28.029 DEBUG: 968.029 - adding material with id undefinedand name default
2017-10-30 20:49:28.029 DEBUG: 968.03 - initial material name : -chest-
2017-10-30 20:49:28.029 DEBUG: 968.03 - copy material chest from chest to None
2017-10-30 20:49:28.029 DEBUG: 968.03 - material chest_B_Clothe_VWD not found
2017-10-30 20:49:28.029 DEBUG: 968.03 - trying to update by index 0 : default
2017-10-30 20:49:28.030 DEBUG: 968.03 - initial material name : -neck-
2017-10-30 20:49:28.030 DEBUG: 968.03 - copy material neck from neck to None
2017-10-30 20:49:28.030 DEBUG: 968.03 - material neck_B_Clothe_VWD not found
2017-10-30 20:49:28.030 DEBUG: 968.03 - index + 1not found in material list while trying to update by index
2017-10-30 20:49:28.030 DEBUG: 968.03 - initial material name : -back-
2017-10-30 20:49:28.030 DEBUG: 968.03 - copy material back from back to None
2017-10-30 20:49:28.030 DEBUG: 968.03 - material back_B_Clothe_VWD not found
2017-10-30 20:49:28.030 DEBUG: 968.03 - index + 2not found in material list while trying to update by index
2017-10-30 20:49:28.030 DEBUG: 968.031 - initial material name : -sides-
2017-10-30 20:49:28.030 DEBUG: 968.031 - copy material sides from sides to None
2017-10-30 20:49:28.030 DEBUG: 968.031 - material sides_B_Clothe_VWD not found
2017-10-30 20:49:28.030 DEBUG: 968.031 - index + 3not found in material list while trying to update by index
2017-10-30 20:49:28.030 DEBUG: 968.031 - initial material name : -pants-
2017-10-30 20:49:28.030 DEBUG: 968.031 - copy material pants from pants to None
2017-10-30 20:49:28.030 DEBUG: 968.031 - material pants_B_Clothe_VWD not found

I think it's related. After forcing one property, i can have at least one material correct instead of one named "default". I've checked all other parameters exposed and there are identical. It doesn't mean anything because a new parameter introduced in 4.9 is not exposed either. The export through the export menu must set this value and it's why surfaces are preserved.

I continue to look into it.

I've reverted to 4.9 as nothing will load into VWD. Once reverted, everything seemed fine.

I have this problem. VWD does not seem to work with hair anymore. I get back an object that only has one surface and the texturing comes out all wrong. I cannot go back to 4.9.

you can contact customer service and see if they'll let you have an old version. TBH; always keep copies of previous releases.

I think I owe you a detailed explanation of the error: When creating a cloth or hair object, VWD export as an obj file the mesh selected. This export has a "Weld seams" option, import it back to create the cloth mesh then export it again. The studio bridge add a further export import after merging duplicate vertices. After the first import, all further exports lack materials, which is new to 4.10 version. I've tried everything to force that export but nothing do. I also tried to remove the additional export-import phase, but then VWD crashes. I'll keep on trying but, if it fails, I have two options. Wait for Daz to correct the bugs (there is a ticket open) or write a new obj exporter (not very difficult, I had to do that for Carrara). whatever the solution is, I'm afraid it will take some time. I'm really sorry about that.

Thanks for the update philemot. I'll stick with 4.9 until you can get this corrected. I see no rush to try dForce when I have VWD and enjoy it as much as I do!

Thank you for the support. I must say it's a hard nut to crack. To be more precise, when you import an obj file, you have to stop the script before you can re-export it. Studio does something when the script is stopped that validate the imported mesh. I haven't found how to reproduce it (and I tried a lot of thing). I'm constrained because the script acts within commands from VWD and it's not easy to change global behaviour.

If you manage to 'fix' it, I'll buy you several beers. I say that in quotes because I realize it's caused by a potentially defective change in studio.

Regardless, I can't stop using VWD because it's just too fun and valuable. To workaround the issue, I've been using an old 4.9 beta install of Daz whenever I need to VWD stuff. Luckily it can open my 4.10 scene files.

Thanks for all your hard work on this! I realize it goes above and beyond the call of duty. I may have to check and see if the VWD script is encrypted or not. I was a software developer for years but got burned out. Playing with this particular script would be worthwhile.

I'd probably go the same path as you, attempt to get rid of the extra export/import, perhaps contacting the VWD creator to see why it crashes thereafter. Failing that...hmm...yeh, tough one.

I now have the answer for the crash. The second export is defective. It exports facets referencing vertices not exported. I'm not surprised the OBJ importer in VWD crashes as it's not supposed to happen. Any script developper can reproduce the error. Using silent OBJ export and import examples from the Daz doc center, You can try to export a mesh, import it back and export again the imported mesh, all in a sequence in the same script.

If you think you can help, I've no qualm sending you the sources. I just have to warn you that some of the code is dynamically generated by translating Python into javascript and executed afterwards, so debugging is not always simple. But the import and export code are in the script (and they are mostly cut and paste from Daz examples).

Hello Philippe,

I don't know if I can do anything to help.

I thought to include the reading of the OBJ file in the program. I will have to rewrite the welding function for the conforming objects. The program will lose in usability but it will work in all situations.

I can get it to work in the 4,10 beta, I do not have the release build installed as still on 4.7 ><

it will fail if you do not clean out temporary dforce files and prob the VWD ones too but I clear out all my temp files and reboot in general as a few programs give me issues otherwise

in particular Carrara which will fill my DAZ temp folder and iClone that fills my C:UsersuserAppDataLocalTemp folder

have done so for years, then it works again till next time!

I do get the single shading domain issue though

Hello,

Visibly, The new Daz Studio version makes the using of VWD impossible. This error is perhaps voluntary or not, It is not important. It is necessary to find a solution to this issue.

I want to bring some informations on the VWD workflow.

My original work has been made for Poser.

In Poser, the workflow needs to export and import the dynamic OBJ several times because the dynamic actor has to be compatible with the Poser Cloth Room.

In Daz Studio, this problem don't exist because the bridge, written by Philippe, generates an animation fully compatible with Daz Studio.

In Daz Studio, It is possible to simply export the actor once. VWD will have to weld the vertices to transform the Conforming actor to a Dynamic actor.

Currently, Philippe used the Python scripts I made for Poser. Perhaps, it is now useful to create a new method which will simplify the process for a use in Daz Studio. It seems it is this double import-export action which generates the issue.

I could send directly an email to Philippe to explain this to him. Certainly, I will send him this email to have a technical discussion with him. I know he has a lot of work and I also think it is important to explain this to all the persons interested by the VWD project.

I hope these explanations will clarify the current problem and also will clarify the need to rewrite a part of the bridge and a part of the VWD program. I hope we will find a solution quickly.

Have a great day.

  Gérald

Hi Gerald. Earlier you mentioned that a single export was possible but would limit some VWD functionality. I don't have your exact words but it was something like that. What sort of functionality would be limited? If it's anything significant I'd probably just stick with Studio 4.9 and VWD as it is now and wish the dForce people well.

I do know other users are finding issues with obj export to other applications too and submitted bug reports namely Octane and Blender so it might yet get resolved if an obj export issue.

After trying everything I could think of (and even other), I've been unable to go around this bug. There are also no news from Daz for the ticket submitted by other Daz users. So I decided to tackle the issue and write my own OBJ exporter. I hope to give you some more news soon.

Unfortunately I haven't gotten around to playing with the export/import. I'm seeing more threads pop up on Daz forums (latest one about GOZ Zbrush bridge) so I have medium hopes Daz will fix it. Then again, ya never know. Here is what we do know from what phil has posted:

Export to weld seams (works fine) Import (works fine) Export (broken - material zones and facets referencing vertices not exported)

So, the second export has been identified as the point of failure. The question is, how does Daz know to fail? I.e., if we have the script just do export/import once (which works fine), close Daz Studio manually, and then re-open and export that mesh...will the 'second' export work fine? If not, then there MUST be something about the post-import mesh which distinguishes it from the other meshes so as to cause the export to fail. IF it works fine, then can close/re-open of Daz Studio be 'simulated' in the script so as to work around the issue.

These are just some random thoughts I had. :)

Hello,

Thank you Philippe for all these tests.

I just want to precise, to explain for Daz users, that when I wrote that Philippe used the Python scripts I wrote for Poser, Off course, Daz Studio don't accept Python script, Philippe had to write a converter. A lot of work.

My current idea is perhaps, to simplify the process. Daz Studio don't need to have this double import/export. It is possible to use only one export. The advantage of this method is that it is simpler. The disadvantage is that the Daz Version will be different from the Poser one.

I can help for the development of the OBJ export, I wrote several OBJ export in my works. In fact, the subdividing process generates another OBJ file in VWD.

I just want to say that I am ready to work a lot to correct this issue. Tell me what I can do.

 Gérald

Hello,

I complete the message I didn't have the time to terminate just now.

@grinch2901 : In fact, the program functionalities would be exactly the sames. I just would like to add some functions which would read a OBJ file and a cache file (.PC2 or .ABC for example). This would allow to start and record a simulation directly in the program without depending on Poser or Daz Studio. For a pose, an OBJ file would be enough. The program would be less user friendly, that's all.

I agree with Philippe, it is necessary to reduce to the minimum the interaction with Daz Studio scripts. Just to keep a user friendly program. All the functions we can write will always be parts that will be impossible to block.

Currently, I continue to work on the GPU programming. I also work on clothes (and hair later) fully compatible with VWD with always the same mesh structure (frontal meshing with a specific size) on which it would be easy to apply precise behaviours. I will send an example in the Freestuff soon.

VWDClothAndHair progresses regularly. :-)

Have a great day.

  Gérald

Custom OBJ exporter is written. Tests are starting today. If all goes right, I'll release a quick fix specifically for 4.10 to allow users to use VWD in 4.10 awaiting repairs from DAZ. It's not a perfect solution because this custom exporter will have to be reviewed a every new Studio release for changes in the internal model. I'd rather use Daz exporter when it works. This export problem is also an issue for other uses of Studio (export to blender or octane for instance) and I think Daz will eventually solve it. Stay tuned for more news

I've created a VWDPython script exclusively for Studio 4.10

It can be downloaded here. Just download in your computer and place near the regular VWDPython.dse file. Click on the new file (VWDPython4-10) instead of VWDPython

Tests are good for me, but I'd rather have other test as well. Could anyone try this script, it would be very helpful.

Woot! We're back in business!

All my surfaces remained in tact. Also, I think it might have eliminated a crash I was getting with one scene on 4.10.

I'm glad you made it a different script in case Daz gets around to fixing Studio export.

You kind of went above and beyond here. I'm excited to have my favorite tool back. Give me an email address or a patreon or something so I can tip. Won't be much but wanted to donate something at least, since it is my fav tool!

PS. Also looking forward to the GPU updates. I realize there may be less incentive now with dForce, but still appreciative the creators keep tinkering away as time permits. Perhaps it's more of a labor of love at this point, lol, but sometimes those turn out to be the best!

Hello

Glad a solution was founded. Bravo to Phil! I hesitate to make the upgrade as I understand that export functionnality is broken. It's a no go for me as I render in Octane via obj exports.

Question: can we have two DS4 version (4.9 and 4.10) installed at the same time?

Daz added a change to their beta release: http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log#private_channel

'Fixed an OBJ export issue when more than one object used the same material name'

I'm reluctant to install Beta to test, but it does look interesting.

Everything is looking good so far. It might be just placebo, but I think the import process is faster now...

Thanks !

Philippe and Gérald,

Thank you so much for your dedication, amazing customer support, and overall pleasant attitude. I'm not affected by this (didn't upgrade Daz to 4.10 yet), but the fact that you guys are so on top of this is awesome. VWD is an essential part of my workflow and, thanks to you, I know it will continue to be so for the foreseeable future!

zanth77 posted at 7:17PM Sun, 19 November 2017 - #4318152

PS. Also looking forward to the GPU updates. I realize there may be less incentive now with dForce, but still appreciative the creators keep tinkering away as time permits. Perhaps it's more of a labor of love at this point, lol, but sometimes those turn out to be the best!

Nah, VWD is still far more powerful and customizable to dForce. One of my favorite things with VWD is how it automagically deals with the body sticking through the clothes. dForce doesn't have that - nor does it allow you to pin and do many other cool things. :)

Using the new DAZ 4.10 bridge script, I tried a Genesis 2 Female with genitalia attached as a collision object I got an error saying "Index de liste hors limites (1)." When I then exited VWD I get "Erreur E/S 103."

Without the genitalia attached, it works fine. I also tried genesis 3 Female with a genitalia attached and that worked fine, but genesis 1 with the female genitalia attached gives the same error.

This error is happening when I set the genesis 1 or 2 character as a collision object. I am not selecting the genitalia which is also in the list.

To be clear, these are the DAZ genitalia that come with the pro bundles. These are not third party genitalia.

I didn't change anything for collision objects because I thought the export bug didn't impact collision. Maybe I was wrong.

By chance, would the material in the genitalia have the same name that materials in the figure. If so, try to rename them, it might get you through.

philemot posted at 1:50PM Thu, 23 November 2017 - #4318586

By chance, would the material in the genitalia have the same name that materials in the figure. If so, try to rename them, it might get you through.

The Genesis 1 and 2 female genitalia surfaces have the same name as the main figure, because they do not need a special texture. You just apply the skin materials for the main character to the genitalia. With Genesis 3 they changed the genitalia to require different material and it has different surface names.

Just removing the genitalia to run VWD seems like a better work around than renaming the surface.

markht posted at 9:53AM Fri, 24 November 2017 - #4318589

philemot posted at 1:50PM Thu, 23 November 2017 - #4318586

By chance, would the material in the genitalia have the same name that materials in the figure. If so, try to rename them, it might get you through.

The Genesis 1 and 2 female genitalia surfaces have the same name as the main figure, because they do not need a special texture. You just apply the skin materials for the main character to the genitalia. With Genesis 3 they changed the genitalia to require different material and it has different surface names.

Just removing the genitalia to run VWD seems like a better work around than renaming the surface.

Didn't dare suggesting it

Glad you're not blocked

Thank you, very much, for your hard work on this. I bought VWD, but have not tried it, yet. I'm really looking forward to this now, though.

Just weighing in to say I risked installing 4.10 and ran VWD using the new script in this thread and it worked perfectly. OBJ export seemed to take a little longer than typical but ut was a dense mesh so might just be that. simulation ran perfectly and transfer back to studio was flawless, all materials there and textured properly. I'm very happy, thanks for the effort to let us stay current with studio and still use VWD!

grinch2901 posted at 9:45AM Sat, 25 November 2017 - #4318641

Just weighing in to say I risked installing 4.10 and ran VWD using the new script in this thread and it worked perfectly. OBJ export seemed to take a little longer than typical but ut was a dense mesh so might just be that. simulation ran perfectly and transfer back to studio was flawless, all materials there and textured properly. I'm very happy, thanks for the effort to let us stay current with studio and still use VWD!

Thanks Grinch!Good to know,I'll, perhaps, make the jump this WE

You can thank Philemot for his great job. I am not so efficient because I continue to have some problems with the self-collision in GPU.

Currently, I also work on a cloth generation. Some of you would be interested by some tests on a cloth reference? This reference will defined by a specific method using a "Frontal" meshing. It would be useful to defined the best size that would allow to define some presets.

grinch2901 posted at 10:11AM Mon, 27 November 2017 - #4318641

Just weighing in to say I risked installing 4.10 and ran VWD using the new script in this thread and it worked perfectly. OBJ export seemed to take a little longer than typical but ut was a dense mesh so might just be that. simulation ran perfectly and transfer back to studio was flawless, all materials there and textured properly. I'm very happy, thanks for the effort to let us stay current with studio and still use VWD!

Yes, I think it would take longer. I've programmed it in script and not C++ and it shows. Remember, it was just a workaround while Daz move the bug correction from beta to production and it didn't seem worthwhile to invest in plugin development.

I have noticed another problem with the 4.10 fixed bridge script.

I do a scene with a hair and use VWD to create a static pose for the hair. I save this scene as DUF, perhaps render it also.

Then I create a new scene using the same character and hair. I use VWD to create a new static pose for the same hair in this scene and save it.

Then I go back and load the first scene. The _VWD object is completely messed up. The origin may have been moved and the hair stretched.

If I rename the hair to have a unique name in each scene, then I don't have this problem. I don't think I had this problem with the old bridge script from before 4.10.

It seems like there is some data files that are generated in common between the two hair _VWD objects from the different scenes and they are being overwritten by later uses of the same hair.

I have not tried this with clothes. Not sure if they have the same problem.

philemot posted at 7:47PM Wed, 29 November 2017 - #4318714

grinch2901 posted at 10:11AM Mon, 27 November 2017 - #4318641

Just weighing in to say I risked installing 4.10 and ran VWD using the new script in this thread and it worked perfectly. OBJ export seemed to take a little longer than typical but ut was a dense mesh so might just be that. simulation ran perfectly and transfer back to studio was flawless, all materials there and textured properly. I'm very happy, thanks for the effort to let us stay current with studio and still use VWD!

Yes, I think it would take longer. I've programmed it in script and not C++ and it shows. Remember, it was just a workaround while Daz move the bug correction from beta to production and it didn't seem worthwhile to invest in plugin development.

Well I've done many more sims since I wrote that and I will say that it really doesn't seem slower at all. Just that one item, which was pretty dense mesh so probably just because of that. It does behave a little differently than before. Specifically before if you changed the materials in the original clothing item, it changed them on the VWD item too. It seems it doesn't now, which is not a big deal. It was also the case that the VWD item would lost materials when you saved the scene and reloaded it, I don't think it does anymore. Essentially it seems the VWD and the original item are not really coupled as tightly as they were, and personally I think that's probably better (a matter of opinion, others may disagree).

Bottom line, your quick and dirty workaround seems to work like a charm. I see no reason why it can't just stay the official method moving forward if you are so inclined. Nice work and thanks for getting it done so quickly.

VirtualWorldDynamics posted at 7:56PM Wed, 29 November 2017 - #4318685

You can thank Philemot for his great job. I am not so efficient because I continue to have some problems with the self-collision in GPU.

Currently, I also work on a cloth generation. Some of you would be interested by some tests on a cloth reference? This reference will defined by a specific method using a "Frontal" meshing. It would be useful to defined the best size that would allow to define some presets.

Gérald, if I understand you correctly you are saying that you could possibly use a different method to generate the triangulated mesh so that the size of the triangles are predictable. Then you can create reference setting for cloth like leather, silk, wool, et cetera because with the mesh density better controlled you can more easily control how it behaves. Is that what you mean?

If so, yes indeed that would be a useful thing to have. Right now I mostly do trial and error, turn down gravity and add some stiffness or even a little inflation to get things to retain their shape like denim or leather might, or tweak other things to get something to drape like silk or whatever. Then for the next item, try again with totally new settings until you I can get it to work in the same way with that mesh. A more consistent method, especially with a preloaded library of cloth types, would be awesome! Then of course a GPU solution would be icing on the cake!