No way to tell obj where to look for materials

Forum rules
Please construct and post a simple demo whenever possible for all bug reports. Please provide links to everything.

If you can include a wad demonstrating the problem, please do so. Bug reports that include fully-constructed demos have a much better chance of being investigated in a timely manner than those that don't.

Please make a new topic for every bug. Don't combine multiple bugs into a single topic. Thanks!

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is ON
[img] is OFF
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: No way to tell obj where to look for materials

Re: No way to tell obj where to look for materials

by Graf Zahl » Fri Nov 02, 2018 11:23 am

I think it should work like all other formats:

Use whatever is present in the model if no skin is set, and use a skin if one is set. This necessitates removing the error message, though.

Re: No way to tell obj where to look for materials

by dpJudas » Fri Nov 02, 2018 11:12 am

Major Cooke wrote:dpJudas: Being able to skip the TEXTURES definition would be appreciated. How about a "Diffuse" property where you can point to the texture file's location?
What I'm saying here is that trying to automatically map the model format's material definitions to engine materials is often a bad idea as the data sets do not fully overlap. Even when they do, there's often problems because paths may not match, one tool might interpret it differently than the other. Subtle stuff like some properties will work, some won't. It is a can of worms.

For those reasons, I'm recommending not trying to support .mtl files directly - or at least only support for pulling out a base texture name for you. I'm not the maintainer of the obj feature, so I'm just voicing my opinion here.

Re: No way to tell obj where to look for materials

by Major Cooke » Fri Nov 02, 2018 11:07 am

Okay, I took a look at it, but the big question is: can it support multiple materials being used? Or do I have to bake and unwrap it?
Because that's the problem I'm facing personally which makes mtl reading far more favorable for things like this. If I scale down the UVs, the textures grow far too large and making different resolutions of textures doesn't help one bit.

Re: No way to tell obj where to look for materials

by Major Cooke » Fri Nov 02, 2018 10:57 am

dpJudas: Being able to skip the TEXTURES definition would be appreciated. How about a "Diffuse" property where you can point to the texture file's location?

Phantom: Sweet! I'll check it out.

Re: No way to tell obj where to look for materials

by phantombeta » Fri Nov 02, 2018 10:56 am

Major Cooke wrote:But deprecating the skin property... How else are we supposed to provide the textures for it? How do you put them in and have them export via blender directly into the model then? I for one have seen NO signs of being able to ever do this. Please do tell me how! I'd love being able to avoid needing to export the skin as well.

Second, if you deprecate the skin property, I don't see how we'll be able to apply materials like specular, normals, and bright maps.
Nash has explained how to do this before, both here and on the ZDoom Discord server.

Re: No way to tell obj where to look for materials

by dpJudas » Fri Nov 02, 2018 10:55 am

I'm not familiar with the contents of .mtl files, but the general approach I've used for materials has been that the base texture name acts as the material name within GZDoom.

For simplicity sake, I don't think it is a good idea to introduce another material format into the mix. If the mtl filename itself can't be mapped directly to a base texture, then we do need some kind of entry in GLDEFS that does this mapping.

Re: No way to tell obj where to look for materials

by Major Cooke » Fri Nov 02, 2018 10:49 am

Jaxxoon, there is a way to do it. As you can see from this image it's possible. This is a bit of a roundabout way but it works.
  1. Create an entry in a TEXTURES lump like this, setting the lump's dimensions to the size of the image (in my case, 1024 x 1024).

    Code: Select all

    Graphic "BFGAmmoSkin", 1024, 1024 
    {
    	Patch "Materials/BFGAmmoSkin.jpg", 0, 0 
    }
  2. Set all your materials into the Auto folders. withe the same name as "BFGAmmoSkin.jpg" or the likes (you can leave the extensions like .jpg in, it'll read them just fine)
  3. Define your model as such:

    Code: Select all

    Model "D4BFGAmmo"
    {
    	Scale 1.0 1.0 1.2
    	Skin 0 "BFGAmmoSkin"
    	Model 0 "Models/BFGAmmoBase.md3"
    	FrameIndex AMBF B 0 0
    }
  4. Not sure if this is actually needed but just in case... Define the material in GLDefs like this.

    Code: Select all

    Material Sprite BFGAmmoSkin {}
If you want to see more on how I did it, check out D4D Alpha 8.3 where I used this method for all the pickup items on ammo, armor, and health.

Re: No way to tell obj where to look for materials

by Major Cooke » Fri Nov 02, 2018 10:42 am

Graf Zahl wrote:Aren't you doing that already?

Regarding this issue, I'm not sure what to do about it. That old skin property was initially meant to override what is set in the model. So the case that a model comes without its internally set skins provided is a valid situation that needs to be considered.

That is, unless we really decide to deprecate that property...
I for starters would LOVE it if a .mtl file could be read so I don't have to deal with the bullshit of having to unwrap/retexture objects I export from GZDoom Builder (which, yes, has that option). This would be a very welcome addition for OBJ formats.

But deprecating the skin property... How else are we supposed to provide the textures for it? How do you put them in and have them export via blender directly into the model then? I for one have seen NO signs of being able to ever do this. Please do tell me how! I'd love being able to avoid needing to export the skin as well.

Second, if you deprecate the skin property, I don't see how we'll be able to apply materials like specular, normals, and bright maps.

Re: No way to tell obj where to look for materials

by Gez » Thu Nov 01, 2018 3:27 pm

Enjay wrote:Having spent a bit of time messing around with models that I have downloaded from a variety of sources and extracted from a fair number of games, it is VERY common for models to have internally set skin names that are different to the graphics files/skins that are actually packed with them (either relying on some game specific config lump to specify them correctly or (if not directly from a game) expecting an end user to create such a lump themselves before they can be used).
And it's still something actively used in modern games, because it's more efficient to have one model, twelve texturesets, and twelve definitions associating the model with a different textureset than the one backed in than to have twelve different models.

Re: No way to tell obj where to look for materials

by Enjay » Thu Nov 01, 2018 1:24 pm

Having spent a bit of time messing around with models that I have downloaded from a variety of sources and extracted from a fair number of games, it is VERY common for models to have internally set skin names that are different to the graphics files/skins that are actually packed with them (either relying on some game specific config lump to specify them correctly or (if not directly from a game) expecting an end user to create such a lump themselves before they can be used). So, under those circumstances, being able to use the skin property to override internally set names is actually very useful.

Moreover, because internally set skin names have historically basically been ignored by GZDoom, there has been no need to ensure the internal name and the skin match. e.g. in my case it's not uncommon for me to have a working name for the model and skin files but I might change them to something more suitable for distribution when packaging up the mod and, of course, there is no reason to edit the model to change the internal name because I can just override it with MODELDEF (so I have done).

Then there is the possibility of different actors using the same model but different skins (e.g. many of the enemies in my Genetech mod - such as the workers, the basic grunt soldiers, the scientists, the civilians and a few others). Without the skin property in MODELDEF, and only being able to use internal names from the model, each new skin would need a new copy of an otherwise identical model too (potentially increasing a mod size by many megabytes).

So, the skin property in MODELDEF is very useful IMO.

Re: No way to tell obj where to look for materials

by Graf Zahl » Thu Nov 01, 2018 4:36 am

Aren't you doing that already?

Regarding this issue, I'm not sure what to do about it. That old skin property was initially meant to override what is set in the model. So the case that a model comes without its internally set skins provided is a valid situation that needs to be considered.

That is, unless we really decide to deprecate that property...

Re: No way to tell obj where to look for materials

by Talon1024 » Thu Nov 01, 2018 4:32 am

So, in other words, I need to make GZDoom read the .mtl files that come with each .obj in order to fix this bug?

Fine...

Re: No way to tell obj where to look for materials

by Graf Zahl » Thu Nov 01, 2018 2:45 am

Only the skin property needs to be deprecated, and hereby I declare it so... :mrgreen:

Re: No way to tell obj where to look for materials

by Nash » Thu Nov 01, 2018 2:35 am

Graf Zahl wrote:The main problem here is that the initial model definition was never meant to solve more than an immediate need loading a Vavoom map properly.
Sadly, when it got expanded to a real feature nobody thought about cleaning up those shortcuts.
Time to deprecate that MODELDEF... :mrgreen:

Re: No way to tell obj where to look for materials

by Graf Zahl » Thu Nov 01, 2018 1:45 am

The main problem here is that the initial model definition was never meant to solve more than an immediate need loading a Vavoom map properly.
Sadly, when it got expanded to a real feature nobody thought about cleaning up those shortcuts.

Top