[IPAndrews]

Workey or no workey? Anyone know?

[Bobboau]

well rotateing subobjects need to be subsystems, and subsystems need to be on a ship, and the universe is not a ship, so, no.

[karajorma]

Although Taylor seemed to want to do something along those lines a while back when we explained that we were having trouble with a fake skybox (basically a big ship with a rotating subsystem) we'd made for BtRL.

[taylor]

Yeah, I tried to get it working previously.  There were just too many blending issues though and the restrictions on what you could actually do kinda sucked.  There are simply too many ways for it to mess up.  I might revist it again in the future, but I have a feeling that it will be so much work for everyone involved (both from a coding standpoint and a mission designer standpoint) that very few people would ever use the feature.

[Bobboau]

I could probably make a solution for this, but it would be very limited.
all you'd basically be able to do would be simple rotations.

[taylor]

I had rotations working pretty easily, but the texture support was very limited.  It would work alright in general, but not without a rather large degree of setup from the person who made the skybox model, and from the mission designer.

[Bobboau]

well I was just thinking of makeing angle a function of time for a new sort of subobject rotation that didn't need to store anything between frames, it could be done without need for subsystems then.

now how that could effect textures I don't know, and it would have about the same level of setup on a per subobject basis as normal rotating subobjects have, unless I'm missing something.

[IPAndrews]

That's fine I didn't expect it to work for the reason Bobboau described. It was for TBP's hyperspace but you probably figured that. Apparently IFH have 3 concentric rotating spheres each with an alpha-channeled texture and it looks spot on. So I was wondering if we could politely steal it and use it.

[DaBrain]

How could I miss this thread.

Yes, SoL would have a use for this feature. Moving clouds in the sky, fake asteroids in Meteo...


There is nothing wrong with the way BtRL did it, but just placing it in the mission and not in the skybox.

However.... this can cause problems in mutliplayer, cause you can't spwan 'in' an object.

[IPAndrews]

Out for us. We've reached our ship limit.

[Bobboau]

http://freespace.volitionwatch.com/blackwater/fs2_open_Bobboau_12-11-06.zip

ok, in submodel properties add

$dumb_rotate:#.#

were#.# is a floating point number.
it should work _every_ware_ (even in the techroom and as backgrounds)

incidentally it's also compatible with the look_at code, so if you use it on a ship, that should still work.
(if you use this on a ship the rotateing subobject will have (unless you do more to the properties, at wich point you might as well make it a full subsystem) no destinction between it'self and the main hull of the ship, it can not be blown up, it can not be targeted, and it does not count as a rotateing subsystem.)

[DaBrain]

Ooooh nice. Now I got something to test when I'm back from work.

[IPAndrews]

Christmas has come early. Time to bug IFH now . If we can get IFH's effect to work is there any chance of getting this code into 3.6.9?

Edit: Actually don't worry about it. I'll just drop both versions of the hyperspace effect in.

[IPAndrews]

Bobboau. You say:

$dumb_rotate:#.#

Where #.# is a floating point number. What does the floating point number repreasent? I just entered:

$dumb_rotate:30.0

And the skysphere rotated what seemed to be... as fast as possible. Looked like a whole revolution in a fraction of a second. I tried 300.0 and it made no difference. I substituted the : for an = to bring it in-line with the other pof submodel properties and it didn't work at all.

[Bobboau]

yeah it needs to be ':'

that's radians per second, wich would be a full rotation every .2 seconds for 30 r/s

[Bobboau]

http://freespace.volitionwatch.com/blackwater/fs2_open_Bobboau_12-30-06.zip

posting a new build, mostly worked on skybox related things so posting it in here.

IP had comunicated that he had a crash useing his model with my build, I have not been able to reproduce this, even useing his model.

this new build supports a few neat little features related to skyboxes.

in the mission file you can now add a few options to your skybox, unfortunately FRED does not suport these yet, but it's only a matter of time.

$Skybox Model:   gasy.pof
+skybox_flags:   ("MR_NO_GLOWMAPS")
+dynamic_skybox

you see the two new options, +skybox_flags: and +dynamic_skybox.
sence +dynamic_skybox is the easiest to explin I'll do it first, this is a bit of a mission flag that specifys that the sky box changes a lot, the only effect it has is that the environment map will be updated every frame (note, this is _->*VERY*<-_ expensive) you should only use this with either highly optimised backgrounds/models or in situations were there aren't going to be a lot of ships in missions (would probly be usefull in 'story' missions).
now, the +skybox_flags: options are probly the more usefull overall, this will give you total controle over how the model is going to be rendered.
the available options are: MR_NO_LIGHTING, MR_ALL_XPARENT, MR_NO_ZBUFFER, MR_NO_CULL, MR_NO_GLOWMAPS.

MR_NO_LIGHTING, no lighting will be applied to the model.
MR_ALL_XPARENT, the whole model will be drawn with additive alpha blending.
MR_NO_ZBUFFER, will not read or write to the zbuffer.
MR_NO_CULL, polies faceing away from the camera will still be drawn.
MR_NO_GLOWMAPS, obviusly, won't use glowmapping.

under most situations you will want to use either all or none of these, but there are some situations were you might find you need just one flag. (if you don't specify any flags it will use: MR_NO_LIGHTING, MR_ALL_XPARENT, MR_NO_ZBUFFER, and MR_NO_CULL by default)

I also fixed a few bugs like stars will no longer draw through a skybox if you don't want it to, though you won't notice any difference if you leave the default flags (as it uses additive alpha)

keep in mind the old -amb and -trans texture flags are still in effect.

[Omniscaper]

Can a skybox support alpha transparancies? I'm attempting to get the faked-skybox background object from this BTRL video http://www.game-warden.com/bsg/Video/BSG_AsteroidField.avi to utilize your rotating skybox so MP spawn problems with objects this large are avoided. Problem is, black keeps rendering as transparent, and the image is an asteroid field silhouette.

[Bobboau]

it SHOULD use the alpha channel, it was in my test. note, you do NOT want to use the trans tag in this situation, just treat it like a normal texture and if it has an alpha channel it will be used.

[taylor]

the available options are: MR_NO_LIGHTING, MR_ALL_XPARENT, MR_NO_ZBUFFER, MR_NO_CULL, MR_NO_GLOWMAPS.

Please don't have use the model-render flags, they are likely to change at any time.  Just use normal flag types, like "transparent", "no cull", "no glowmap", "no lighting", etc.  That's easier for everyone to deal with.

[IPAndrews]

Omniscaper, alpha transparencies definitely work.