Color tool on prop_physics changes rendergroup, but not SENTs?

How come when I set the color of a prop_physics with alpha < 255, it’s rendergroup becomes RENDERGROUP_TRANSLUCENT, but when I do it with a SENT, it stays the same? How do I change the render group of my SENT from opaque to translucent when its alpha is changed?

[editline]21st February 2016[/editline]

Do I just make the SENT always RENDERGROUP_TRANSLUCENT?

[editline]21st February 2016[/editline]

Should I use RENDERGROUP_BOTH?

[editline]21st February 2016[/editline]

I’ll do that, but I’m just wondering why prop_physics rendergrouping behaves differently from gmod SENTs.

Props also automatically change to RENDERGROUP_TRANSLUCENT if the model they’re using has translucent materials, but SENTs don’t, meaning you can get rendering issues where the translucent material doesn’t show up in front of stuff. If your SENT is something that players can set to literally any model they want, then there’s no easy way to detect this yourself short of manually checking all the materials for things like $translucent and $alphatest, which is silly.

It doesn’t. The color tool is made to set the render mode for you if you did not select a custom render mode in the color tool. It used to do that in the engine, but it made HL:S entities invisible.

The SetColor function does not do this.

[editline]22nd February 2016[/editline]

You guys are confusing render groups with render modes!

[editline]22nd February 2016[/editline]

AFAIK Render groups decide what gets drawn when ( before or after what, for depth purposes ), render mode decide HOW the entity is rendered.

No, we’re talking about render group. Render mode of the SENT will be changed same as prop_physics when the color tool is used on it, but won’t be translucent because the rendergroup isn’t changed. Probably because the device context doesn’t have alpha enabled whenever it does the opaque pass.

[editline]21st February 2016[/editline]

Can’t a prop_physics be literally any model you want?

Nvm I see what you’re saying. RENDERGROUP_BOTH might be the fix for this.

Ok, I see the problem.

The problem, exactly, is that ENT.RenderGroup is overriding the engine’s default action, which is applied to all entities that do not override this behavior.

I am not sure how it should behave. Should ENT.RenderGroup always take precedence over the engine default? ( current behavior ), should it only do that if it is set? Or should ENT.RenderGroup only be set once and be able to be overridden at any time?

IMO it should be that the lua defined rendergroup takes precedence, and have developers update the rendergroup when needed (maybe have an entity hook that’s called when something happens to the entity that might require a rendergroup change)

Nothing needs to change. This system was put in place probably so other rendergroups would be compatible with color changes. If anything though, the default for SENTs should be RENDERGROUP_BOTH instead of RENDERGROUP_OPAQUE. Idk if RENDERGROUP_BOTH has any performance impacts though.

I’d say the second option (engine default is only overridden if ENT.RenderGroup is set) sounds the best out of the three, but it could potentially break some SENTs (without ENT.RenderGroup set) because a color or model change could cause them to start running ENT:DrawTranslucent() instead of ENT:Draw(), which they wouldn’t have had to expect before.

It would still be nice to have the option for a SENT to use the engine functionality, though, even if it isn’t enabled by default. ENT.RenderGroupAuto = true, ENT:RenderGroupAuto(true), or something like that. Whatever the cleanest way to implement it would be.

I like the ENT.RenderGroup only being set once option.