vBF2/PR 3dsMax Tools - Import/Export/Lightmaps/Animation - Max 9 and newer!

[[R-CON]​Harmonikater]

Well now it's a different issue, but one I cannot replicate.
Could you possibly send the offending maxfile?

[[R-DEV]Mineral]

https://www.dropbox.com/s/wfxocj45epgqoge/1.max?dl=0

[[R-CON]​Harmonikater]

This is acually a import bug (at least in the scene above), somehow a material is being given information that neither the bf2 materials nor the exporter can handle. (Somehow there's a bump texture with a map that has no filename, hence the string errors.) Don't know why yet.
Export worked fine for me after replacing the offending material (the one with only objects\vehicles\common\textures\ger_vehicleglass_ c.dds). with a new one (with the same texture map) from scratch.

I did find a bug regarding alpha materials that resulted in much more materials being created
than necessary, but it doesn't seem to be related. (But good that I found it in the process of looking for the other one, so thanks for that)

I can't reproduce the same import with the 341 or gazelle thats in the PR files. And either i'm blind or the 342 isn't the files yet. I'd need those as well to check why the import is mucking up.

[[R-DEV]Mineral]

Yeah 342 is something new we are trying to get ingame I noticed the duplicate alpha materials as well. Wasn't sure if it was worth reporting. The ger_vehicleglass material is something I made I think. Wasn't by import. Was trying to replace the current glass material with a new one. So maybe something to do with a new BF2 material being made with that faulty parameter? Or when making a copy of another material and removing the bump map? Just speculating what might have happened.

[Psyrus]

Incredible work! I'm floored by this, I never thought anyone would go to the effort of recreating (never mind improving!) all this functionality for the newer versions.

[Outlawz7]

I haven't had the chance to check this out yet but did anyone try the OG lod tool mentioned in OP?

Harmonikater, can you also add these scripts to the tools menu?

meshcheck.ms - Checks mesh for thin triangles. Use this to pinpoint custom lightmap UV errors.
objexp.ms - A minimal Wavefront OBJ exporter that doesn't suck. Use this for BF2 undergrowth.

Battlefield Mod Tools

As said, being able to import and lightmap destroyables would be (even more) awesome since until now that's something 3ds Max LM tools couldn't do.

Also while at the moment we can export static objects with custom LM UVs, we still need to use BFMeshView to generate samples for them, any way to add generating custom LM UV samples into exporter?

[[R-CON]​Harmonikater]

Originally Posted by [R-DEV]Outlawz7

Also while at the moment we can export static objects with custom LM UVs, we still need to use BFMeshView to generate samples for them, any way to add generating custom LM UV samples into exporter?

This is actually a very good point.

Bad news is that I can't touch the actual sample generation since that's done in the SceneParse binary.

However, I generally assume that BfMeshView generates better samples anyway. So I went ahead and packed the relevant BfMeshView code into a small command line tool that generates samples based on a couple of input parameters, in the same way that BfMeshView does.
Therefore any staticmesh export will automatically have BfMeshView-like samples by default. (Though the old SceneParse samples can still be picked by adjusting a setting in the Setup window.)

Consequently, custom LM resolutions are possible with the next version:

[worldlife]

Hi Harmonikater,
I've been working on improving this 3dsmax tool this summer, and when I see this post.. OMG You have done almost everything I want to do/have done, and many things I didn't consider to do! The alternative import, support for higher versions, what a coincidence isn't it! Excellent work!
Anyway, I'll just talk about what I've done that you haven't done.

1.My importer(also based on Remdul's meshman code) supports skinnedmesh import with skin modifier. The skin info can be inferred from the blend weight part in vertex info. Also it supports bundlemesh import with animated UV setup and skin modifier, which info can be inferred from the blend indices part and uv2 part in vertex info.
By the way, did you solve the smoothgroup problem? Like when you import and export vBF2 RUTNK_T90, the main barrel's smoothgroup is destroyed.

2.About lightmapping destroyable object. Destroyableobjects lightmaps itself and do not cast shadows, so I use exclusion in light objects' shadow settings(or maybe global shadow settings is better). Just add this in StaticObjects_Import.ms

global g_bf2Level_SupportedObjTypes_Noshadow = #("destroyableobject")

and add object type check in bf2LoadObjCon, and name them with a "noshadow_" prefix. And when importing the sun, add those objects with "noshadow_" prefix to the excludeList of the light and set inclExclType 2(shadow exclude).

3.Changed some rollout codes to provide Localization support. This is done by changing the caption of the rollout objects on open. Like this:

on rollbf2test open do
(
	--localization
	btnExport.caption = LOC_EXPORT_btnExport
	chkPause.caption = LOC_EXPORT_chkPause
	...
)

LOC_EXPORT_btnExport is a global string value stored in a localization file. Choose file to include according to the language setting.

Feel free to contact me if you need more details.

[AfterDune]

Harmonikator, I don't know where you suddenly come from, but your work is sooo appreciated!!

[[R-CON]​Harmonikater]

Originally Posted by worldlife

1.My importer(also based on Remdul's meshman code) supports skinnedmesh import with skin modifier. The skin info can be inferred from the blend weight part in vertex info. Also it supports bundlemesh import with animated UV setup and skin modifier, which info can be inferred from the blend indices part and uv2 part in vertex info.
By the way, did you solve the smoothgroup problem? Like when you import and export vBF2 RUTNK_T90, the main barrel's smoothgroup is destroyed.

That's something I've wanted to include but haven't had the time yet. It wasn't super high priority for me, since skinnedmesh imports tend to be not very useful imo.
If you're going to change the actual mesh the skin modifier will likely go to hell anyway.
I guess if you want to change just the weights on some parts, that could work, but you'd still have the additional vertices where the exporter detached due to smoothing group changes.
Unless one were to manually weld verts during import while keeping the smoothing groups intact and then applying the imported skin weights based on vertex position or something like that. But I'm afraid that could become fairly complex and resource-intensive pretty quickly.
Of course it would also benefit normal non-weighted meshes in the end as well.
But in my experience just letting max weld and autosmooth leads to too many errors.
Think of a small cylinder whose ends the player doesn't see, there's no problem in making it 4-sided with one smoothing group around. That create obvious problems for autosmooth.

Then again I'm doing everything in maxscript, if this were done in SDK the entire import would probably a hell of a lot quicker. Unfortunately I have no experience with max SDK, but maybe you do? (You didn't mention how you implemented your importer)

In any case, would you mind sharing your code here?

Originally Posted by worldlife

2.About lightmapping destroyable object. Destroyableobjects lightmaps itself and do not cast shadows, so I use exclusion in light objects' shadow settings(or maybe global shadow settings is better). Just add this in StaticObjects_Import.ms

global g_bf2Level_SupportedObjTypes_Noshadow = #("destroyableobject")

and add object type check in bf2LoadObjCon, and name them with a "noshadow_" prefix. And when importing the sun, add those objects with "noshadow_" prefix to the excludeList of the light and set inclExclType 2(shadow exclude).

I've already done something like this for Object children that shouldn't cast shadows (also on a per-object basis), like RotationalBundles, i.e. for FH2 mostly windmill sails.
I guess with destroyableObjects it's again a matter of what's the least bad option, since there is no perfect one. Do we want there to be no shadows cast at all onto terrain and surrounding statics? (In FH2 there's a big destroyable Anti-Tank wall which stands in line with other Or assume that the Object will spend more time being alive than destroyed and have only geom0 cast shadows? (In which case we'd have to make sure that geom0 isn't casting shadows onto its own geom1) What's the usual opinion on this? (Again don't have a mapping background, so don't know how this is commonly handled)

Originally Posted by [R-DEV]AfterDune

Harmonikator, I don't know where you suddenly come from, but your work is sooo appreciated!!

Thanks! I've mostly been lurking on the PR forums for the Tutorials and whatnot, (especially while I was starting out), since it's a much more comprehensive collection than over at FH2.