[niffiwan]

I need the opinion of those that *know skyboxes*.  Per this mantis ticket, the set-skybox-model sexp ignores what the default missions skybox flags are and it just uses some defaults.  I want to know if the experts consider it reasonable to copy the missions default skyboxes flags for any skybox set by set-skybox-model, OR if it would be a far better idea to provide access to individually set each skybox flag when calling set-skybox-model. IOW, a tradeoff between complexity and control.

For this specific issue raised in mantis (i.e. to clamp or not to clamp) it would seem reasonable to use the same flag all mission, the reasoning being that someone creating skyboxes for a mission is likely to create multiple skyboxes using the same method.  Of course... that doesn't help someone who is reusing other peoples skyboxes...

ANYWAY, I can fix this either way, but I lack the domain-specific-knowledge to pick the best solution, hence my request for opinions

[General Battuta]

More control, no question.

[niffiwan]

Yeah, that was my 1st thought too, my hesitation stems from the fact that set-skybox-model seems to have been used a reasonable amount already without problems so the defaults look like they mostly work. And unnecessary complexity is counter-productive. Still, there's no reason that any new arguments can't be optional and order independent.

i.e. all options, each flag toggles the defaults

( set-skybox-model "CS-SB.pof" [add-lighting | no-transparency | add-zbuffer | add-culling | no-glowmaps | add-clamp] )

Default case (same as current implementation)

( set-skybox-model "CS-SB.pof" )
Uses flags MR_NO_ZBUFFER | MR_NO_CULL | MR_ALL_XPARENT | MR_NO_LIGHTING

Sexp to add CLAMP to the defaults:

( set-skybox-model "CS-SB.pof" "force-clamp")
Uses flags MR_NO_ZBUFFER | MR_NO_CULL | MR_ALL_XPARENT | MR_NO_LIGHTING | MR_FORCE_CLAMP

Sexp to add lighting to the defaults:

( set-skybox-model "CS-SB.pof" "add-lighting")
Uses flags MR_NO_ZBUFFER | MR_NO_CULL | MR_ALL_XPARENT

Does that seem clear and intuitive?

[zookeeper]

I take it that it'd take a variable amount of arguments, so you could set however many of those flags you want instead of just one?

[niffiwan]

yes, it'd be a variable number up to 6 (or 7 if you include the 1st required argument)

i.e. to flip/toggle all the flags away from their defaults:

( set-skybox-model "CS-SB.pof" "add-lighting" "no-transparency" "add-zbuffer" "add-culling" "no-glowmaps" "add-clamp")

[The E]

Apart from me having not the slightest clue what lighting on a skybox is supposed to accomplish, this is a good idea (also, related to that, glowmaps on skyboxes make no sense either)

[zookeeper]

I suppose lighting on a skybox could be used if, for example, the skybox features land or a planet which you want to be lit by a moving sun.

[The E]

That would be an idea, except it doesn't work. In order to figure out which lights to use when rendering a model, the renderer needs a valid object number, which skyboxes do not have.