ZLZ PRP Importer

[Sirius]

Thanks for the input, I'm beginning to see what the problem might be.
The texture blend type being set to "Multiply" should usually cause no issue for materials - it's required for proper alpha blending if I remember correctly. It also forces the texture to be tinted by the material's base color, which is always either white, or one of the "debug" colors like yellow, cyan, purple, etc - it's a bit redundant since those colors are always visible in Solid view, but again it should theoretically be no issue as the material is never fully black. If you really need to disable it, paste the following line into Blender's interactive Python window:

Code: Select all

for m in D.materials:
    for slot in m.texture_slots:
        if slot:
            slot.blend_type = "MIX"

However, I tried importing the GuildPub-Messengers.age, and everything looks correct on my end, so this is quite weird. Are you sure it's not caused by something else, like moving the light sources to another layer ?

[Tsar Hoikas]

Opened a PR that addresses the issue of animations not being imported from MOUL ages.

[Sirius]

Cool My knowledge of how animations work across various PRP formats was quite limited at the time, so this is a good thing.

Animations import has always been quite buggy anyway. It doesn't correctly account for parenting, and causes exceptions on some occasions. At some point I should see if it can be improved further...

[Tsar Hoikas]

Any issues preventing the merge of #1 into mainline ZLZ?

[Sirius]

Nothing aside from my dumb brain keeping forgetting to actually validate the merge :/ My bad, will do it ASAP. Once again thanks for the contribution !

EDIT: Done. People looking for the upgrade can head over to the Wiki page, download the latest version and install it the same way they did with the last.

[Sirius]

Thought I would say: I'm currently working on improving ZLZ. Since Doobes has shown a lot of interest in making a Blender version of Cyan's Ages recently, I'm focusing on maximizing compatibility with Korman. While it doesn't import puzzle logic, at least ZLZ can now setup most of Korman's modifiers on its own. Modifiers are usually present on lots of smaller objects throughout Cyan's Ages (such as sound emitters and cameras), so this should be a massive help !
If anyone has suggestions for features they would like to see in the importer, feel free to tell me and I'll see if I can include it in the next version

[Deledrius]

Excellent! I submitted a merge request with some work I did last year before Thanksgiving and Christmas took over (and other RL events, too). It contains some fixes and upgrades for working with Korman I made that Doobes has been using for the last few months. Hope that helps!

[Sirius]

Great ! From a quick glance, I think I already have all those features in. I'll have a deeper look and steal any improvements your version may have Thanks !

Since the importer is getting more complex, I'm currently rewriting most of the SceneImporter anyway. The old version has a lot of duplicate or unclean code, as well as flaws that make setting up Korman modifiers painful, or will break on any cross-PRP plKey. New version should be much cleaner.

Right now I'm also trying to fix wrongly positioned colliders from MOUL PRPs. In PotS, guessing whether colliders are in local or world space was pretty easy, but it's rather messy in MOULa. Plus, Cyan artists enjoyed using negative non-uniform scaling on some detector regions. Fun times !

[Deledrius]

Great ! From a quick glance, I think I already have all those features in. I'll have a deeper look and steal any improvements your version may have Thanks !

Aww, that's a shame. They've been on the fork since November, but I guess you didn't see them. Hope it helps anyway.

Right now I'm also trying to fix wrongly positioned colliders from MOUL PRPs. In PotS, guessing whether colliders are in local or world space was pretty easy, but it's rather messy in MOULa. Plus, Cyan artists enjoyed using negative non-uniform scaling on some detector regions. Fun times !

If you could elaborate on this, I wonder if it might help a problem we've found with some colliders when libHSPlasma exports for PotS. A lot of things seem to show up at the origin when they shouldn't. Is this related? How can you tell which space to use in MOUL and PotS?

[Sirius]

Aww, that's a shame. They've been on the fork since November, but I guess you didn't see them. Hope it helps anyway.

I didn't know this fork existed, I can't find any mention of it on Gitlab. Oh well, it's alright.

If you could elaborate on this, I wonder if it might help a problem we've found with some colliders when libHSPlasma exports for PotS. A lot of things seem to show up at the origin when they shouldn't. Is this related? How can you tell which space to use in MOUL and PotS?

Sure.

PotS is fairly simple, collisions are in local space only if you give the object a non-zero mass (and optionally make it kPinned so it doesn't fall). As far as I can tell, there are no exceptions in Cyan's PRPs since they are all setup the way I described a while ago (other configurations might have unexpected results, personally I always kept to Cyan's way of doing things and had no issue).

MOULa is more complex. It appears there isn't a straightforward way to tell if it's local or world space. However, the following appears to work fairly well so far (at least for importing):

• The physical's position and rotation attributes (<Transform> in PRC) should be ignored for importing.
• Collisions are world space only if all the following conditions are met:
  
  • mass is zero
    
  • no kPinned or kPhysAnim flag
    
  • NOT a member of the Detector group
    
  • NOT a member of the LOSOnly group
    
  • bounds MUST be convex hull
• Additionally, the Offset property of box bounds must be ignored.

I tested it with MOUL's Eder Tsogal and Gahreesen's exterior, and it works correctly despite the animations, negative collision scaling, etc.
Never had issues in PotS, just checking the mass is enough.
Myst V appears to import correctly if you assume collisions are always in local space.
I will have to do more testing for all game types though.
The Well's exterior collision mesh in Gahreesen is the only physical at the wrong location so far - there seem to be some subworld shenanigans at work here, but it's an edge case and I've never seen a similar issue in other PRPs, so I'm not going to bother with it.

And here is my current version of the physics importer, which sums it all up.

physImporter.txt

(9.87 KiB) Downloaded 782 times

(You'll notice it also creates a Korman collision modifier )

Like I said, this is only for importing. Exporting with Korman may allow people to run into other configurations for which the above may not work.