Gumboots wrote:Hey hang on a doggone minute. I haz another idea. This one might even be useful.
Since the .3dp import process drops information for normals, it follows that if you took one of the flat-shaded .3dp's and imported that into Blender, then exported it straight away using the smooth-shaded script, it should fix the problem.
Note that I said "should". Might be worth trying.
Well, I tried several formats, POV-Ray, Lightwave, AutoCAD/AutoDesk, etc., none of them worked any better. (a few of which stripped the UVmap off the mesh )
I then tried you latest idea, importing and exporting a flat-shaded 3DP with the smooth-shading script. Still flat-shaded, but at least the UVmap didn't go on vacation
"We have no patience with other people's vanity because it is offensive to our own."
-- François de La Rochefoucauld. Réflexions ou sentences et maximes morales. 1665.
Gumboots wrote:Is the new Mogul smooth-shaded in your RT3 installation?
Smooth shaded. So I am at a loss.
"We have no patience with other people's vanity because it is offensive to our own."
-- François de La Rochefoucauld. Réflexions ou sentences et maximes morales. 1665.
Ok, which version of Blender are you using? Every so often the nutters in charge change the syntax for various bits. I know the script works with 2.74 to 2.76, but can't vouch for it on other versions.
I'm using 2.74 for RT3 stuff but I wouldn't even try to guess which subversion. There's a date and time on the splash screen: 2015-03-31 13:39
I will try another version and see where it goes.
"We have no patience with other people's vanity because it is offensive to our own."
-- François de La Rochefoucauld. Réflexions ou sentences et maximes morales. 1665.
Since posting last night, I've tried the 32bit and 64bit versions of Blender 2.74, 2.75, 2.75a, 2.76, 2.76a, and 2.76b.
I've checked my Python install for issues, none detected. Python 2 is 2.7.12 (vers. 2.7.13 came out of beta on 17 Decemeber). Python 3 is 3.5.0, until 2 days ago, the latest stable release for Windows (vers. 3.6.0 came out of beta 2 days ago).
I tried a number of antique model formats that do not carry any embedded shading or UV information. Upon exporting the otherwise unproblematic file to 3DP, I still get flat-shading in RT3 format.
This simply proved that on my system all model formats work/appear as expected in Blender. I've tried the script in the archive and the version you shared last night. I've gone through the script line by line and all is as it should be.
If I import a random PopTop 3DP, in Blender, it is always flat-shaded even if the same model is smooth-shaded in RT3. When I import any of the models I have made, in Blender, they always appear smooth-shaded until they pass through the 3DP export, then they appear flat-shaded in Blender (just like a random PopTop 3DP), but are also flat-shaded in-game, unlike your Mogul.
So, having parsed this thing out, we can safely say:
• It's not a problem with Blender (you used Blender to debork the Mogul)
• It's not a problem with Python (you used Python via Blender to debork the Mogul)
• It's not a problem with the script (you used the script to debork the Mogul)
• It's not a problem with Milkshape 3D (proven by using roughly a dozen formats without shading or UVmapping data)
• It's not a problem with AutoCAD/AutoDesk (proven by using roughly a dozen formats without shading or UVmapping data)
• It's not a problem with RT3 (the game engine is simply rendering what it reads from the file)
Ergo, it has to be one of three things:
• An ID-10-T error, a.k.a. EBCAK, since this process is pretty soundly idiot-proof, not highly likely
• A system issue.
• A discrete issue with the model itself. I cannot think what that would be, but I am including it as a possibility.
That's where my idea well runs dry.
I'm attaching a RAR file with my model and game files for the problem child for you to look over when you have the time. It's not a mission critical matter and in a fairly crude state, just enough to test in Blender and in-game, and nothing more. The most I'm hoping for is that you can see something that helps fix the overarching issue on my end.
"We have no patience with other people's vanity because it is offensive to our own."
-- François de La Rochefoucauld. Réflexions ou sentences et maximes morales. 1665.
I'll happily take a look. This is intriguing, and if you've hit this problem it's a safe bet somebody else will too, sooner or later.
The .3dp's importing as flat-shaded to Blender is normal. Flat-shaded is Blender's default mode in the absence of any other information. Since Blender doesn't import any .3dp information re shading, the imported files default to flat. I just set them to smooth after importing, unless it's a face I particularly want flat.
Which is weird. The model appears to be fine, since it smooth-shades on my box. The Mogul is fine on your box and on mine. Beats me why you're getting flat-shading on the Martian beastie on your box.
Ok, this just breaks my head. I just tested the same PK4 before posting it and it was flat-shaded. I just looked again and it was smooth-shaded. All that had changed was I rebooted the computer in the time in between. It makes no sense that a reboot would change shading properties.
"We have no patience with other people's vanity because it is offensive to our own."
-- François de La Rochefoucauld. Réflexions ou sentences et maximes morales. 1665.
Much ado about nothing... *mutter* I had just posted about being able to rely on the RT3 EXE not reacting well to change in the building thread....
I think the EXE likes to play jokes...
In any event, thank you for testing the PK4. At least now we know the problem isn't me finding some way to muck up an idiot-proof thing. But, I will strive to do better in the future.
"We have no patience with other people's vanity because it is offensive to our own."
-- François de La Rochefoucauld. Réflexions ou sentences et maximes morales. 1665.
Just a thought, but it may have been a caching or addressing glitch. So if you had started with the flat-shaded script but then changed to the smooth one, perhaps the game and/or Windows somehow cached the model data for the flat model and stuck with that until reboot. Can't think what else it could be.
There are several times that I have fought with Windows memory caching hanging on to old data. I filed bug report after bug report before finally being told it was a sacrifice made to get the "fastest booting Windows ever". At the same time, I was told that "Windows certified software" didn't cause the problem... Funny thing, Age of Empires III has a Windows certified emblem on the CD case, yet....
Sometimes, I think it would be refreshing to hear the truth from a software rep. But, then, I just might fall over dead of surprise.
"We have no patience with other people's vanity because it is offensive to our own."
-- François de La Rochefoucauld. Réflexions ou sentences et maximes morales. 1665.
For importing, what I do is manually split the hex file into the appropriate number of custom .3dp files (usually 5 for a locomotive body) and import those one at a time, each to their own layer.
For exporting, the reverse. Export to five custom .3dp files, then merge them manually in a hex editor.
If anyone wants to know: I've just upgraded to the latest version of Blender (2.79b) and this still works perfectly with that version, so there's no need to stick with older versions to use this add-on.
While hunting down arcane details of 1.06, I found something in an old thread about exporting models:
Milo said long ago that he made something to read them into Blender, but not to go back out to 3DP; the problem was the iterations of "INST" segments in the file.
It seems that if not for that detail, this site would have been able to have a Blender import/export plug-in available ten or more years ago. Of course, using a hex editor to paste the LOD's together manually is a piece of cake. I do them all the time and it's no drama. There's no need for the script to handle that detail (the current script doesn't anyway) but apparently Milo thought that would be a killer and consequently gave up on the idea. If he hadn't been so worried about that detail, the whole history of RT3 asset modding could have been different. Funny how things turn out.
Just looking into updating this thing, since Blender is up to version 2.90.1 now and I know they broke old add-ons with the 2.80 series.
Although they claim 2.90.1 is stable it is pretty new, and it came out not long after 2.90.0, which implies maybe it's not quite as stable as they'd like it to be. Their download page says "Update now for a more stable 2.90 experience".
And if all else fails, read official instructions (which are bound to be gruesome): Blender 2.80: Addon API
So between that lot, and provided adequate amounts of swearing are indulged in, it should be possible to get the thing running on 2.8x and (maybe) 2.90.x (if anyone cares).
Won't be trying it this week myself, but anyone else is welcome to have a crack at it.
Still haven't done anything about updating this script, but have been doing some reading. Apparently Blender is now up to version 3.2, and they are planning to do a Long Term Support version of 3.3, with release planned for September 2022 and full support until September 2024. It is probably worth looking at updating the RT3 import/export script then, so I will see how feasible it is.
However, RT3 uses Gouraud shading for rendering assets, and it turns out the best way of emulating that is to use the internal Blender rendering engine, and that was only available in pre-2.8 versions of Blender (2.8 and up use the Cycles engine instead). It's probably possible to create Gouraud shading in 3.3, but it would have to be custom coded (bleh). Also, the later versions of Blender are more resource-intensive to run, with requirements for 3.2 being:
Minimum
64-bit quad core CPU with SSE2 support
8 GB RAM
Full HD display
Graphics card with 2 GB RAM, OpenGL 4.3
Recommended
64-bit eight core CPU
32 GB RAM
2560×1440 display
Graphics card with 8 GB RAM
Even the minimum is beyond the specs of my current box, although it's likely that for RT3 modelling this would not matter much, since the requirements are written to handle for some pretty serious animation work.
Anyway, the older script will always be available, and Blender 2.79 will always be available, so there should be no trouble modelling RT3 assets on lower-spec boxes for quite some time.