Lugaru Map Import / Export scripts for Blender

[rudel_ic]

In line 127 of lugaru_map_import.py, it says:

Code: Select all

factor = 0.25

Change that to

Code: Select all

factor = 0.3

[ChosenOne]

Ok. This is a big improvement. But still not accurate.
And apparently, there's a difference in accuracy if the objects are created in Lugaru, then re-arranged in Blender and exported back to Lugaru -OR- created in Blender, by means of duplication (SHIFT+D), arranged in Blender, then exported to Lugaru.

Please see my image studies:

First image illustrates my workflow creating objects in Lugaru, then importing into Blender, arranging as needed, then exporting back to Lugaru and checking the results by flying around.






This second image illustrates my workflow duplicating objects in Blender that were initially created in Lugaru, also arranging in Blender, then exporting back to Lugaru and checking the results. I moved Turner to a few different areas of the resultant "structure" in order to see how accurately things join up.




SYNOPSIS
Changing the factor variable to 0.3 seemed to only affect objects created in Blender.

[ChosenOne]

Furthermore, in Lugaru I tried saving the map depicted in my second image above, as a different map file ("cubes02") then imported that into Blender.
Inspecting the adjoining corners of the 5-cube "structure" I made out of duplicated boxes I find that they're correct - the corners match up perfectly, just like they do in Blender before exporting to Lugaru and using Lugaru to save it as "cubes02".
I would expect the objects' coords to be botched in Blender, just like they appear to be in Lugaru.



*EDIT Hmm, interesting note on the script's behavior - If I import a map's contents into Blender, then go alter the factor variable, then use the script again in the same Blender file and import the same map again all imported objects - those imported before and after altering the factor variable value, are all moved to coincide with what the script currently has in it. Very odd.
In between using the script, you must press the "exit" button to make it reload the new edits if you change it.

Whoa this is crazy, I was about to submit this edit to this post but switched over to continue playing with the script a little - I kept importing different versions of the cubes map I've got, even altering the script's factor value in between imports. Well this last time I go ahead and import another previous version that has the several smaller cubes I was going to arrange snapped to the larger one.
How crazy is it that when I did it this last time the smaller cubes are perfectly arranged with each other - 4 on bottom, and 4 on top making two identical tiers of cubes, so that, together, they comprise a perfect whole cube.
But then I go back and look at the other sets I've imported into this map and I see the same thing happened to them when I used the script this last time as well.

[rudel_ic]

I think the placement discrepancy is because there's ANOTHER factor named fac in line 410 that's also 0.25.
Set that to 0.3 as well and see what happens.

The reasoning behind this:

The center of Lugaru's box is slightly off, meaning that the object center isn't at the vertices' median. See here:

The purple dot is the object center, the blue dot is the vertices' median.

The factor in line 410 affects the scaling as well as the positioning. Blender scales from its object center, same goes for the location.

Unfortunately, changing the scaling and location of objects upon import means that the landscape mesh isn't accurate anymore for imported objects! I'll give you the right landscape scaling value once I've found it.

[rudel_ic]

The slightly inaccurate placement inside Lugaru is a separate issue, by the way. We'll deal with that as well though.

[rudel_ic]

Note that in lugaru_map_merge.py, in line 304, the factor is 4.0. We need to change that to 1.0/0.3 (which is 3.3333.....). This will of course introduce a rounding error.

It was 4.0 before because 0.25 (the old importing factor) times 4 is 1.0

Edit: An entirely different approach would be taking the values as they are; unfortunately, this exceeds Blender's visibility range pretty fast.

[ChosenOne]

Whoops, notice my "*EDIT" up there. Just additional info, nothing actually changed in my post.



Ok, I see "fac = 4.0" in line 304. Is that it? I see nothing about fac in 410. There's no ".25" or "o.25" anywhere in the script. Search comes up with no hits.

My line 410 reads "# nodot = 1".

So my only change is on line 304, which now reads:

" fac = 1.0/0.3"

Let's see what happens.

[ChosenOne]

Map attached.

cubesallaligned.zip

(216.83 KiB) Downloaded 620 times

[ChosenOne]

Let's see what happens.

Still having same problem. What do your experiments look like?

[rudel_ic]

Before you change anything, I propose you wait it out. I'll attach fixed scripts when we're satisfied, and you can just use those. Otherwise, it's hard to communicate mistakes I've made and want to take back and stuff.

So I've ditched all extra factors right now except in the mesh import code in the function named importSolid in lugaru_map_import (around line 127).
That means that scaling and placement isn't being messed with. Consequently, inside of Blender, the stuff is at different places.

The result is proper placement:


There's still the problem with the terrain though. We could just ignore that for the moment. I'll have to find a more accurate and efficient method for heightmap mapping in Blender anyhow.

Do you want to work without the terrain for the moment?

[rudel_ic]

Attached are the fixed scripts. Replace the scripts you currently have.
Note that the landscape mesh (the green big thing from the screenshots in the original post) wouldn't match the object placement in this patch, so don't work with lugarumapping.blend.

I propose you place meshes as "landmarks" for orientation, approximate object placement in Lugaru, refine in Blender.

Do not use Blender files that are the result of old imports with these scripts. Scaling and placement has changed, so it doesn't make sense to use stuff that's been generated with outdated methods! Import your Lugaru maps anew into empty Blender files and work from there.

Note that these scripts still limit the maximum amount of objects to merge into a map to 299. If you've changed that in a previous release, you'll have to change it again!
Instructions for this: viewtopic.php?p=111859#p111859

[ChosenOne]

Yes, I can work without the terrain being accurate for the time being, sure.


I've plugged in your new scripts. Big improvement. Though the objects seem better placed, consistently, whether created in Lugaru or in Blender, they're imported into Blender way away from the terrain mesh now. I guess you noticed. But if you export your Blender work back to Lugaru the objects are back over the mesh. They only appear to be way off the terrain in Blender, in Lugaru they're fine. This does render the starter Blender file with the terrain already in place of no use, just like you already said.

Also, all this testing is only with boxes. Might the other objects have different placement problems?

What if we just edited each of the 12 map objects 3D files' to be correctly aligned to center on all 3 axis'? Let's say we do update all 12 files, in essence fixing the median points problem - they're different in Blender and in Lugaru.
Would that cause maps created with the old objects to be outdated, since with the new objects, with fixed coords, all map objects in-game would move around a little since the median points differ? Does that make sense?

I really appreciate all the help so far!




Find here my current Blender file and Lugaru map file experiment - newcubes02. See how everything is snapped together precisely in Blender, but in Lugaru things are different. Note that the lower "structure", closest to the ground, was made by duplicating Lugaru-created objects in Blender. As mentioned above, there's no difference between the placement of objects created in Lugaru and those created in Blender, by duping Lugaru objects.

newcubes02.zip

(1.03 MiB) Downloaded 557 times

[rudel_ic]

Also, all this testing is only with boxes. Might the other objects have different placement problems?

It doesn't look like it. There's the known rotational caveats for rocks, platforms, bushes and trees (see OP); that's pretty much it.

What if we just edited each of the 12 map objects 3D files' to be correctly aligned to center on all 3 axis'? Let's say we do update all 12 files, in essence fixing the median points problem - they're different in Blender and in Lugaru.

The thing is that in Lugaru, the median is calculated and that's the center; in Blender, the center is assumed to be (0,0,0) (that's at least true for my .solid import/export stuff). For absolutely accurate results, it would be necessary to clone the median calculation from Lugaru. So if you're making a new .solid in Blender, after you've created the mesh, you have to calculate the Lugaru median and transform the vertices in Edit Mode so that the object center and the Lugaru median are exactly at (0,0,0). When you export that, you have a .solid that scales identically both in Lugaru and Blender, and in Blender identically both in Object and Edit Mode.
The issue though is that this takes a bit of freedom away from the modeler. Sometimes, you _want_ the center of an object to not be the median. Swords are an example for that. Same goes for lampposts, walls, trees... There's lots of cases.
And the only thing you gain is identical scaling, which isn't a huge gain, considering the loss of freedom.
Sure, your maps might look a tad wonky, but I don't think that's an issue unless you want to mimick fabricated products with .solid elements.

Would that cause maps created with the old objects to be outdated, since with the new objects, with fixed coords, all map objects in-game would move around a little since the median points differ? Does that make sense?

If you move mesh vertices, your maps will have different meshes with entirely different scaling outcomes, different rotation outcomes and so forth; so yes.

Find here my current Blender file and Lugaru map file experiment - newcubes02. See how everything is snapped together precisely in Blender, but in Lugaru things are different. Note that the lower "structure", closest to the ground, was made by duplicating Lugaru-created objects in Blender. As mentioned above, there's no difference between the placement of objects created in Lugaru and those created in Blender, by duping Lugaru objects.

What I note is that the cubes are below ground (you probably have a custom heightmap?). When I move them above ground, I notice that the meshes aren't precisely where they are in Blender. But we're talking relative centimeters.
I think that you can indeed eliminate that discrepancy with fixed centers (s.a.). I don't think it's worth the trouble. That's your decision though.

There might be some flag for scaling operations that makes Blender use an arbitrary point as the scaling center. I haven't found it so far though. The Blender documentation for scripting sort of sucks.

What you want to do if you want to fix .solids by hand so that their median is their center and both are at (0,0,0):
- Check how the median is calculated in Lugaru
- Check whether Blender has this median calculation (I'd guess it does, it's probably either the Median Point or the Bounding Box Center; see pic below)
- For each Lugaru .solid:
— Figure out the median:
——— In Edit Mode, press A until all vertices are selected
——— The median is at the blue dot's coordinates
— Transform all vertices until the aforementioned median is precisely at (0,0,0)
— Confirm that both the object center and the object median are at (0,0,0)
— Export



Pic below lol

[ChosenOne]

Rudel, just an update - I haven't forgotten about this. I'm currently waiting on some changes in the source code to be made before I make more progress. Thanks again for the great support on your scripts.
Hopefully, I can share the next development soon.

[Lotus Wolf]

Just an update on my testing (I got the patched scripts);
Here's some incomplete architecture I've been working on in my spare time. This may become part of a mod of mine, so this is for private use only (however, I encourage the placing of enemies on the map). It's a mix of hand-placed(Blender), editor-placed(Lugaru) objects, built with the foundation of the original 4th challenge. I put all the objects on the map before moving, resizing, rotating and duplicating them, in this way (I think), none of the placements were messed up. I love the scripts so far, very precise, great stuff.
-Lotus