104 réponses à ce sujet

[rjshae]

I've overhauled this plug-in so that it will work with Blender 2.68.

http://neverwinterva...rtexport-plugin

Please let me know if you run into any issues. Thanks.

[kamal_]

you just made rolo_kipp very happy.

[Rolo Kipp]

<grinning...>

Yup yup :-)

Now, if only someone would completely parse the Granny2 format and make in importer/exporter for *that* :-P

<...like a fool>

[henesua]

nice

[Happycrow]

Will this work for the stable 2.69 release? If so, this would be enough to get me going back to my local Blender group.

Thanks, this has been SORELY needed.

[rjshae]

Thanks, everybody.

Happycrow wrote...

Will this work for the stable 2.69 release? If so, this would be enough to get me going back to my local Blender group.

Thanks, this has been SORELY needed.

It seems to work: I installed 2.69 and was able to import, edit, and export a model without any error messages.

What I haven't gotten around to testing yet are the SKIN and armature Import/Export.

I added some troubleshooting notes in the messages section.

Modifié par rjshae, 02 novembre 2013 - 03:51 .

[rjshae]

Aww crud, I discovered a problem.

I wanted to take a walkable placeable and place it at a 15 degree angle. The import went fine, as did the edit. However, when I exported the placeable and tried it in the toolset, I found the walk mesh was rotated 180 degrees with respect to the rest of the placeable.

Bollocks. Well I'll see if I can figure out a fix...

----

Edit: I'm wondering now whether this might actually be a problem with Blender. I performed a negative rotation on the object mesh and the bounding boxes, then manually edited the walk mesh to match up. (There's probably a better way to do it, but I'm a Blender newbie.) Perhaps the rotation was applied incorrectly when Blender generated the tessface data I used for export? Shrug.

Modifié par rjshae, 02 novembre 2013 - 04:50 .

[Happycrow]

I'm not good in Blender: I"m a 3dsmax guy who'd prefer to shift that direction: armature import/export.... armature equates to skeleton?

[rjshae]

Happycrow wrote...

I'm not good in Blender: I"m a 3dsmax guy who'd prefer to shift that direction: armature import/export.... armature equates to skeleton?

Yep, I guess that's what they call it in Blender.

[rjshae]

My first primitive attempt at using the add-on was to create sloped boarding ramps for Heed's Walkable Ships hakpack:



I think I'll have a few uses for these bad boys...

Modifié par rjshae, 02 novembre 2013 - 10:27 .

[Happycrow]

oooooooh. I could use that TOMORROW once I finished retexturing it...

[rjshae]

As I use this thing I'm discovering some additional issues:

• If some of the images used by the model are not available in the model's directory, the Import fails. I've got a fix in my code that seems to at least prevent failure and should give a hint about what's missing (in the outliner tree).
• Renaming the imported parts causes an export to fail. I've got part of this problem fixed; other parts I'm still investigating.
• Sub-dividing the WALK mesh causes it to export in a very unsatisfactory manner. It bakes, but the walk mesh is messed up.
• A rotation transform may not be applied correctly on export. I wiil need to experiment a little more to see if this is something I can fix.
• I was able to import hook points from one model and export them in another. However, the export doesn't record their updated coordinates; it just saves the old coordinates and orientation. (I think I've found for this one now; the fix will probably also work on the rotation issue.)
• Export relied on a single global variable to track whether alpha transparency is in use. However, some models only implement alpha transparency on a subset of the RIGD objects. Instead, I'm going to use the 'use_alpha' setting on the diffuse texture.

At some point I'll try to put out a patched version.

Modifié par rjshae, 05 novembre 2013 - 01:24 .

[PJ156]

Good luck Bob, it sounds like you will be doing us a huge favour getting this fixed. I'm not familiar with blender but I think I am going to be

PJ

[rjshae]

On Heed's Boardable Ships, functioning doors have been implemented for the Cargo Ship, Warship, and Ghostship models. To get it to work, I imported hook points from a house model and relocated them on the imported ship models. (The existing faces with the door textures had to be removed.) It took a couple of fixes to the import/export scripts to make it work right, so those will be in the next release. One thing I discovered was that a vertical walk mesh on the decks can prevent a door from being selectable. But shifting a few vertices on the walk mesh slightly (so the hook point was exposed) got it working properly.



Hopefully those who like ship-borne adventures will find this useful.

Modifié par rjshae, 05 novembre 2013 - 02:34 .

[rjshae]

In experimenting with models downloaded from the Vault, I found a critical defect in some of the Export functionality. There's a piece of code that's supposed to identify matching vertices from different faces and set them to the same vertex. However, in some cases the current code can end up adding more vertices. The resulting export looks all kinds of messed up. Thus I'm going to have to rewrite that part of the code--hopefully it'll be fairly straight forward.

The problem usually only shows up on models with vertices that are shared by a lot of faces. For simple and/or nicely meshed models it seems to work okay.

Anyway, I'm still working on the patched version. I hope to have it out soon--maybe later this month.

[rjshae]

I've found what appears to be a data corruption issue with the mesh duplication code in Blender. If I import a model with a lot of parts, when I try to export it the duplication call (sometimes) randomly zeroes out some of the stored data for objects in memory. (I can see it when I store a copy of the data and compare the before and after values.) When I just export the parts directly, I don't get the data corruption effect.

That's... a problem. I was using the duplicated mesh to apply the transform() call, which would store the data with all the rotation and translation applied. If I apply the transform to the objects directly, then it applies the transform on top of the existing changes, effectively doubling whatever changes I made.

Ack! Well I guess that's what you get with open source code. A work-around is to save the content to a file, perform an export, then reload. But that's a royal nuisance.

----
Ed.: The good news is that just working directly with the meshes rather than trying to copy them cleaned up the previous problem mentioned above (although the texture mapping doesn't export nicely--I'll need to work on that.)

Modifié par rjshae, 09 novembre 2013 - 12:51 .

[rjshae]

I uploaded a bug-fix version of the add-on to the vault. This fixes a number of issues I've encountered; most importantly it corrects a problem (from the original code) that can result in some horribly stretched textures. It seems to be working reliably now and I've been having good results, so if you're already using the add-on I strongly recommend updating to this release.

The one known issue that I gave up trying to fix (for now) is the application of the transform matrix prior to export. Cloning the meshes for this purpose resulted in some badly mangled models, so I had to work with the original data. Unfortunately, this can cause a double application of the transform. If you have been moving objects around, my suggestion for a work-around is to do the following:

-- Prior to exporting to an MDB file, save the content to a blend file.
-- Perform the export.
-- Restore from the saved blend file.

This should put things back the way they were. The Blender Roadmap for 2.7X mentions, "Fix our duplicator system ... (for local parts of linked/referenced data)", so perhaps I can address the problem at that release?

Thanks.

----

Here's what I'm looking at for future improvements:

-- On import, add an input field that allows you to specify a value for reducing the WALK mesh Z-coordinates when they are at -1000000 (including leaving them at the default of -1000000). The export will have a corresponding field to specify a Z-coordinate below which they will be restored to -1000000. (I've already got this working and it is proving most helpful for editing WALK meshes.)

-- On import, provide a 'New name'  input field  that will be substituted in the names of all object that have the 'model file name' as a prefix. This should simplify the tedious task of renaming all the parts for export. (Doing so has proven necessary to avoid clashes in NWN2).

-- Eliminating the use of the 'upper()' string class calls that are setting object component names to upper case. I don't understand why this was being done (other than possibly the above), but removing it hasn't resulted in any issues.

-- I need to do some testing of models other than Placeables and see if they import/export okay.

-- There are a couple of MDB elements that are not handled by the add-on at present: Hair and Helm points. I want to see if I can incorporate those.

-- What about wing attachment points? Do they have their own data block? Time to use Hex Editor Neo again...

Modifié par rjshae, 11 novembre 2013 - 09:02 .

[rjshae]

While testing more object types I found that there has never been an export set up for SKIN packets... ACK!

Okay, that's added to my to-do list. For now I just about have the HELM import/export working.

More work to do.

Ed.: Okay that's not quite true. There's an option you can set on export to make it do SKIN packets. But the import always adds an ARMATURE modifier to a SKIN, so I think I can use that as a flag to check for SKIN exports.

Rolo Kipp wrote...
Now, if only someone would completely parse the Granny2 format and make in importer/exporter for *that* :-P

Yeah, that would be good. Comparing the data patterns in the NWN2 gr2 files, it looks like the bulk consists of a series of integers followed by a series of floating point numbers. I'm guessing those are probably skeleton components? We might be able to match up the number of integers with the floats and divine a purpose. Perhaps they consist of part codes/bit flags and vertex coordinates? If just the skeleton data could be extracted, that might be a start. Shrug.

Modifié par rjshae, 20 novembre 2013 - 03:41 .

[kamal_]

What I would dearly like is a global find/replace for textures on object parts. For instance if I want to append "codi_" to each of the texture maps (screen is from gmax, but you get the idea)
https://dl.dropboxus...ppend_codi_.jpg

A find replace for part names would also be extremely useful.

These things would vastly speed up my tile project.

[-Semper-]

jus wanted to stop by and drop a big thx!
it's nice to see that you're still working hard to update the plugin. i am currently using tazpn's tools but i am sure that yours will surpass it soon. there's really a need for future proof tools with integrated animation support. guess it's time to refresh my rusty blender skills

[Rolo Kipp]

<running away...>

rjshae wrote...

Rolo Kipp wrote...
Now, if only someone would completely parse the Granny2 format and make in importer/exporter for *that* :-P

Yeah, that would be good. Comparing the data patterns in the NWN2 gr2 files, it looks like the bulk consists of a series of integers followed by a series of floating point numbers. I'm guessing those are probably skeleton components? We might be able to match up the number of integers with the floats and divine a purpose. Perhaps they consist of part codes/bit flags and vertex coordinates? If just the skeleton data could be extracted, that might be a start. Shrug.

There's a bit Here, and There and other There...
And even some bits hidden in the mysterious vanishing hull bit Here...
Edit: Holy Moly! Almost forgot the Magic Block! (search for it on This page ;-)

<...from hostile grannys>

Modifié par Rolo Kipp, 21 novembre 2013 - 11:29 .

[rjshae]

kamal_ wrote...

What I would dearly like is a global find/replace for textures on object parts. For instance if I want to append "codi_" to each of the texture maps (screen is from gmax, but you get the idea)
https://dl.dropboxus...ppend_codi_.jpg

A find replace for part names would also be extremely useful.

These things would vastly speed up my tile project.

I found a couple of Python scripts that will let you do batch renames:

• Batch Rename Datablocks
• Batch Naming

The second one looks more promising, but I haven't tried either. Will that help?

-Semper- wrote...

jus wanted to stop by and drop a big thx!
it's
nice to see that you're still working hard to update the plugin. i am
currently using tazpn's tools but i am sure that yours will surpass it
soon. there's really a need for future proof tools with integrated
animation support. guess it's time to refresh my rusty blender skills

Thanks, -Semper-. I'm still airly new to a lot of this stuff and haven't looked at any of the Blender animation tools yet. I suspect I'll need to figure out how to import the armature/skeleton. But that's just a guess.

Rolo Kipp wrote...
There's a bit Here, and There and other There...
And even some bits hidden in the mysterious vanishing hull bit Here...
Edit: Holy Moly! Almost forgot the Magic Block! (search for it on This page ;-)

Good stuff, Rolo! Thanks. I took a swing through the data trying to decipher it, but what looked like floating point data came out pretty squirely. These will definitely help.
At present I've got all of the changes I wanted to make
working: both HELM and HAIR import properly, although I need to do some
more testing of those models. There's a couple of other enhancements I'm
also working on, as well as stamping out a few more bugs.

Modifié par rjshae, 22 novembre 2013 - 01:50 .

[kamal_]

rjshae wrote...

kamal_ wrote...

What I would dearly like is a global find/replace for textures on object parts. For instance if I want to append "codi_" to each of the texture maps (screen is from gmax, but you get the idea)
https://dl.dropboxus...ppend_codi_.jpg

A find replace for part names would also be extremely useful.

These things would vastly speed up my tile project.

I found a couple of Python scripts that will let you do batch renames:

• Batch Rename Datablocks
• Batch Naming

The second one looks more promising, but I haven't tried either. Will that help?

If I could figure out how to get them running. I got your importer/exported running without too much trouble, but I have zero Blender experience (and only started with gmax to work with the tiles).

[rjshae]

Oops, it looks like they moved the Batch Naming script to here.

You're supposed to be able to install it by selecting User Preferences (under File) then 'Install from File...'. But it is not showing up in the selection list. Maybe there's something wrong with the bl_info in the script?

Modifié par rjshae, 22 novembre 2013 - 03:04 .

[rjshae]

As an experiment, I added some code to allow an ascii MDL file (from NWN) to be imported. The result is shown below. It doesn't appear possible to map the face-based UV coordinates in the MDL file to the vertex-based UV coordinates in an MDB file, so I just assigned the first value found at a vertex. That likely resulted in the texture stretching that appears in the pic. Anyway, do you think this type of import could be useful? Or perhaps it's just too redundant with Neverblender.

Modifié par rjshae, 22 novembre 2013 - 05:10 .