ZDoom

by **Marisa the Magician** » Wed Aug 21, 2019 3:16 am

See now you're just going way too far ahead. That's something that has to wait first for the animation system overhaul.

by **Deybar_TECH** » Tue Aug 20, 2019 4:58 pm

Sorry but it would not be a better idea to adapt the controls and options of (MODELDEF) directly to the properties of the (Actor)?

Code: Select all

// these flags are for filtering actor visibility based on certain conditions of the renderer's feature support.
// currently, no renderer supports every single one of these features.
enum ActorRenderFeatureFlag
{
	RFF_FLATSPRITES		= 1<<0, // flat sprites
/////>>>>>RFF_MODELS			= 1<<1, // 3d models
	RFF_SLOPE3DFLOORS	= 1<<2, // sloped 3d floor support
	RFF_TILTPITCH		= 1<<3, // full free-look
	RFF_ROLLSPRITES		= 1<<4, // roll sprites
	RFF_UNCLIPPEDTEX	= 1<<5, // midtex and sprite can render "into" flats and walls
	RFF_MATSHADER		= 1<<6, // material shaders
	RFF_POSTSHADER		= 1<<7, // post-process shaders (renderbuffers)
	RFF_BRIGHTMAP		= 1<<8, // brightmaps
	RFF_COLORMAP		= 1<<9, // custom colormaps (incl. ability to fullbright certain ranges, ala Strife)
	RFF_POLYGONAL		= 1<<10, // uses polygons instead of wallscans/visplanes (i.e. softpoly and hardware opengl)
	RFF_TRUECOLOR		= 1<<11, // renderer is currently truecolor
	RFF_VOXELS		= 1<<12, // renderer is capable of voxels
};

Since there is a constant parameter within the GZDoom itself called (RFF_MODELS) and only a flag like this should be added or simply use this same flag on the objects so that their (sprites / frames) disappear and the Modeldef properties can be used. And so, add a (ModelStyle {<model index = 0> <model Style = MShaded>}) and that can be modified later in gameplay with a (A_SetModel-Style, Alpha, Scale, Frame, Angles, Offset, Flag {< model index> <effect>}) with this. I assure that more people will start using more 3D models instead of (sprites).

by **Marisa the Magician** » Mon Aug 19, 2019 2:15 am

I'd suggest a Style/SurfaceStyle property for modeldef if all of this actually is doable.

And yeah, as beta has mentioned, transparent model parts have their quirks when it comes to drawing order. It's not hard to account for this though. For example in blender all you'd need to do is rearrange the materials for the object so translucent ones are at the top.

by **Deybar_TECH** » Sun Aug 18, 2019 4:00 pm

I need a lot of transparency control in the models.
but it is possible that this may be a reality in the future like (A_SoundPitch)

by **Enjay** » Tue Aug 13, 2019 6:36 am

Marisa Kirisame wrote:I think I asked before if it was possible to make each surface in a model have a different renderstyle but was told that no?

That's part of why I have asked if it can be done with separate models on the same actor, rather than different surfaces in the same model having different translucencies.

by **Marisa the Magician** » Tue Aug 13, 2019 4:36 am

Enjay wrote:Does it really need to be encoded in the model though?

Well, at least one of the supported model formats already supports providing renderstyle information.

Whether that information is usable, that's another story. I think I asked before if it was possible to make each surface in a model have a different renderstyle but was told that no?

by **phantombeta** » Mon Aug 12, 2019 6:51 pm

AFADoomer wrote:Alternatively, implementing proper model rendering support for translucency in .png skins could work, too... Right now model skins seem to render as fully opaque unless the alpha value at that point on the texture is zero, so you can't just use a translucent texture to get this effect.

This has already been done, you just have to set the renderstyle to Translucent. Do note, however, that you'll very likely have depth sorting issues - possibly even between the model's own triangles.

by **AFADoomer** » Mon Aug 12, 2019 6:38 pm

Alternatively, implementing proper model rendering support for translucency in .png skins could work, too... Right now model skins seem to render as fully opaque unless the alpha value at that point on the texture is zero, so you can't just use a translucent texture to get this effect.

by **Nash** » Mon Aug 12, 2019 5:21 pm

Enjay wrote:Does it really need to be encoded in the model though?

GZDoom clearly has the ability to show an actor that uses a model with translucency. I'm not asking for some bits of one model to be translucent and other bits not to be. I'm asking for "draw this model opaque, and that one translucent". It just so happens they would be attached to the same actor - but maybe that kind of separation isn't possible in GZDoom? Perhaps the underlying actor's renderstyle limits it to one type and one type only?

e.g. something like this from an end-user perspective is what I'm talking about:
Code: Select all
Model ModelCar
{ 
   Path "Models" 
   Model 0 "Car.md3" 
   Skin 0 "Car.png"
   Model 1 "CarGlass.md3" 
   Skin 1 "CarGlass.png"
   Scale 1.0 1.0 1.0
   
   ModelRenderstyle 1 Translucent 128
   
   FrameIndex POSS A 0 0
   FrameIndex POSS A 1 0
}
Obviously model 0 would default to normal rendering.

I'm sure, if it's possible, something much better could be thought out, but that shows the principle of what I'm talking about.

This *might* be possible, but it adds into the pile of "let's just duct tape a new feature on to MODELDEF instead of doing it right".

I mean, I'm not nay-saying, it's just that Graf has already expressed how unsatisfied he was with regards to MODELDEF, as far as adding features to it is concerned.

Still, if someone can hack this in a PR and if it is deemed an acceptable submission, I wouldn't complain. I'd probably use it.

by **Enjay** » Mon Aug 12, 2019 4:17 pm

Major Cooke wrote:What code are you using to move the child actors around with it? Perhaps I can help with that part, in the mean time, at the very least.

I've done a few things in the past (DECORATE and ACS - not done anything with ZScript yet) and I usually end up seeing 1-tic jerkiness as things catch up to their intended position.

Simpler actors that I used in the past (ones that were just intended to be static) would simply spawn the second (and even third*) actor on top of themselves in their spawn state. So, that created two actors on the same spot looking as if they were one. That was all well and good until I put one on a conveyor belt that had a teleport line at one end to return it to the start of the conveyor. The two parts quickly went out of sync.

*Actually, that reminds me, something else that could be useful is the ability for a model to not replace a sprite. One of the 3-part actors I was talking about had a sprite component, an opaque component and a translucent component.

Spoiler:

by **Enjay** » Mon Aug 12, 2019 4:09 pm

Does it really need to be encoded in the model though?

GZDoom clearly has the ability to show an actor that uses a model with translucency. I'm not asking for some bits of one model to be translucent and other bits not to be. I'm asking for "draw this model opaque, and that one translucent". It just so happens they would be attached to the same actor - but maybe that kind of separation isn't possible in GZDoom? Perhaps the underlying actor's renderstyle limits it to one type and one type only?

e.g. something like this from an end-user perspective is what I'm talking about:

Code: Select all

Model ModelCar
{ 
   Path "Models" 
   Model 0 "Car.md3" 
   Skin 0 "Car.png"
   Model 1 "CarGlass.md3" 
   Skin 1 "CarGlass.png"
   Scale 1.0 1.0 1.0
   
   ModelRenderstyle 1 Translucent 128
   
   FrameIndex POSS A 0 0
   FrameIndex POSS A 1 0
}

Obviously model 0 would default to normal rendering.

I'm sure, if it's possible, something much better could be thought out, but that shows the principle of what I'm talking about.

by **Nash** » Mon Aug 12, 2019 2:59 pm

Yeah, this information needs to be encoded into the exported model directly. Not sure where would be the best place to put this - I suppose it could be encoded per mesh group.

Neither MD3 nor OBJ have this kind of data in their original specs, so anything done here would be GZDoom-exclusive. Currently-existing exporters would also have to be updated to actually write this data so that GZDoom can make use of it.

(inb4 "GZDoom needs a new model format" ;))

by **Major Cooke** » Mon Aug 12, 2019 9:46 am

As much as I would love this (not only for the aforementioned but also to cut down on actor count), I doubt it's possible without making changes to the MD3/OBJ formats themselves... maybe? Perhaps OBJ might already have support for it in some degree, but Nash will have to comment on the MD3 models.

What code are you using to move the child actors around with it? Perhaps I can help with that part, in the mean time, at the very least.

by **Enjay** » Mon Aug 12, 2019 6:59 am

Or something that achieves the same goal but does it better?

Specifically, I'm thinking of actors that use multiple models where one of the models needs to be translucent but the rest don't.

e.g. 1 a vehicle would need its bodywork to be fully opaque, but the glass in its windows would be translucent. If the body was one model and the glass was another that could be set to be translucent, that would be ideal.

e.g. 2 a old fashioned street lamp with a solid metal frame and glass panels around its light source.

Obviously from the above screenshots, I've managed to fake it in the past by making the object two separate actors, each with their own models; one for the opaque bits and another with a translucent renderstyle for the bits you're meant to see through. That works well enough if you don't want the object to move but it can quickly fall apart (literally) when the actor needs to move.

Maybe there is a neat way of doing this already?

ZDoom

MODELDEF Translucency property?

Post a reply

Expand view Topic review: MODELDEF Translucency property?

Re: MODELDEF Translucency property?

Re: MODELDEF Translucency property?

Re: MODELDEF Translucency property?

Re: MODELDEF Translucency property?

Re: MODELDEF Translucency property?

Re: MODELDEF Translucency property?

Re: MODELDEF Translucency property?

Re: MODELDEF Translucency property?

Re: MODELDEF Translucency property?

Re: MODELDEF Translucency property?

Re: MODELDEF Translucency property?

Re: MODELDEF Translucency property?

Re: MODELDEF Translucency property?

MODELDEF Translucency property?

Post a reply

Expand view Topic review: MODELDEF Translucency property?

Login • Register