No way to tell obj where to look for materials
Moderator: GZDoom Developers
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!
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!
No way to tell obj where to look for materials
[g3.6pre-57-g2d1043d1d]
With the new obj-format models there's no way to point to the materials defined within them, leading to warnings in the console. Neither placing the mtl files in the model's directory nor in the materials directory prevents this. Even removing materials on the model altogether simply causes them to leave an error about not finding a material called "none."
With the new obj-format models there's no way to point to the materials defined within them, leading to warnings in the console. Neither placing the mtl files in the model's directory nor in the materials directory prevents this. Even removing materials on the model altogether simply causes them to leave an error about not finding a material called "none."
- Attachments
-
- obj.pk3
- (69.83 KiB) Downloaded 101 times
-
-
- Posts: 374
- Joined: Mon Jun 27, 2016 7:26 pm
- Preferred Pronouns: He/Him
- Graphics Processor: nVidia with Vulkan support
- Contact:
Re: No way to tell obj where to look for materials
Here's my writeup on OBJ support
GZDoom looks for materials for OBJs in TEXTUREx, TEXTURES, and full paths.
GZDoom looks for materials for OBJs in TEXTUREx, TEXTURES, and full paths.
Re: No way to tell obj where to look for materials
Does this mean that there is no bug here?Talon1024 wrote:Here's my writeup on OBJ support
GZDoom looks for materials for OBJs in TEXTUREx, TEXTURES, and full paths.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: No way to tell obj where to look for materials
I think it means that it doesn't look in the model definition's material path - which would definitely be a bug. This should be consistent for all model types.
-
-
- Posts: 374
- Joined: Mon Jun 27, 2016 7:26 pm
- Preferred Pronouns: He/Him
- Graphics Processor: nVidia with Vulkan support
- Contact:
Re: No way to tell obj where to look for materials
The OBJ code throws those "material not found" errors while it is parsing the OBJ file, so it has no idea about SurfaceSkin replacements until you start playing on a map with the OBJ models, since curSpriteMDLFrame is not updated until the game decides to render the models. I could print a warning from RenderFrame if a certain material is not found, but I don't want to spam the console with 'Material X not found' warnings while the player is ingame, although it would be nice to notify the modder about missing materials.
On the other hand, it doesn't look like the other model formats throw warnings about missing materials either. Is the best solution to remove those warnings, or am I completely misunderstanding this bug report? I mean, the models from the pk3 are visible ingame on the demo map.
On the other hand, it doesn't look like the other model formats throw warnings about missing materials either. Is the best solution to remove those warnings, or am I completely misunderstanding this bug report? I mean, the models from the pk3 are visible ingame on the demo map.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: No way to tell obj where to look for materials
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.
Sadly, when it got expanded to a real feature nobody thought about cleaning up those shortcuts.
Re: No way to tell obj where to look for materials
Time to deprecate that MODELDEF...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.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: No way to tell obj where to look for materials
Only the skin property needs to be deprecated, and hereby I declare it so...
-
-
- Posts: 374
- Joined: Mon Jun 27, 2016 7:26 pm
- Preferred Pronouns: He/Him
- Graphics Processor: nVidia with Vulkan support
- Contact:
Re: No way to tell obj where to look for materials
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...
Fine...
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: No way to tell obj where to look for materials
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...
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
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.
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
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.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).
- Major Cooke
- Posts: 8170
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Location: QZDoom Maintenance Team
Re: No way to tell obj where to look for materials
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.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...
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.
- Major Cooke
- Posts: 8170
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Location: QZDoom Maintenance Team
Re: No way to tell obj where to look for materials
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.
- 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 }
- 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)
- 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 }
- Not sure if this is actually needed but just in case... Define the material in GLDefs like this.
Code: Select all
Material Sprite BFGAmmoSkin {}
Last edited by Major Cooke on Fri Nov 02, 2018 10:55 am, edited 1 time in total.
Re: No way to tell obj where to look for materials
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.
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.