Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: IPAndrews on December 06, 2006, 09:40:51 am
-
Workey or no workey? Anyone know?
-
well rotateing subobjects need to be subsystems, and subsystems need to be on a ship, and the universe is not a ship, so, no.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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. :(
-
Out for us. We've reached our ship limit.
-
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.)
-
Ooooh nice. Now I got something to test when I'm back from work. ;)
-
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.
-
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.
-
yeah it needs to be ':'
that's radians per second, wich would be a full rotation every .2 seconds for 30 r/s
-
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.
-
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.
-
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.
-
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.
-
Omniscaper, alpha transparencies definitely work.
-
Alpha transparencies work, but the problem is that black also acts as a transparency, and the opaque areas designated by my alphas are black. I tried off black colors, but the value changes just affect level of black transparency. Using Mr_All_xparent flag makes the black visible again, but nullifies the alpha channel. I'll try rearranging the subobject order, perhaps the transparent subobjects are not rendering behind it, but I isnt, mr_nocull suppose to take care of that?
-
Alpha transparencies work, but the problem is that black also acts as a transparency, and the opaque areas designated by my alphas are black. I tried off black colors, but the value changes just affect level of black transparency. Using Mr_All_xparent flag makes the black visible again, but nullifies the alpha channel. I'll try rearranging the subobject order, perhaps the transparent subobjects are not rendering behind it, but I isnt, mr_nocull suppose to take care of that?
Which was always the problem when I was working on this for you guys. Adding support for moving skyboxes took all of 30 minutes. But after a week of playing around with everything I just couldn't get an acceptable resolution to the texture blending issue. It is simply too constrictive to work, or at least it was the way I had coded it. Hopefully Bobboau will have some better ideas than I did.
-
no cull allows polygons that are faceing away from you to be drawn, it doesn't effect draw order.
you need to set you subobjects so the furthest away draw first
no_zbuffer _might_ prove usefull at some point
it's up to the model maker to resolve texture sorting issues.
if you could give me your model, I might be able to figure out how to get it to work the way you want.
-
I tried rearranging the subobject order so rendering order is correct. The the pof renders correctly as a ship.tbl entry. As a sky box with a color other than black, it renders correctly. The black level of the texture adjusts the level of transparency in ADDITION to the alpha channel.
On the plus side it does rotate and looks as good as my previous fake-skybox object approach. Now if only it can render the same way a normal ship.tbl pof does.
My next workaround for this transparency problem is to make asteroid shaped polygons instead of a cylinder with texture transparency of asteroid images. No doubt this will raise polygon numbers insanely, but its the only solution I can think of at.
On another topic, my reason for embracing this feature is for MP functionality. IIRC, subobject rotation only appears on the host machine, not the client. Does this skybox rotation work on the same rotation principal? I have yet to try this build with MP because of its debug build
-
looking at the pof ast1,2,and 3 are in reverse order than what they should be.
also ast_starfield.dds, and starfield0001.dds have no alpha layer.
-
also, the model options are MISSION options, they go in the mission file, it's text just like the tables. they don't go in the model anywere, so it's still drawing them like normal bgpofs, additive everything.
-
wait a sec, the subobjects are rendered in reverse order :doubt:
ok, you should make everything into subobjects as to lessen the already confuseing situation.
then the order should be ast1,2,3, back, starfeild.
and add
+skybox_flags: ("MR_NO_GLOWMAPS")
+dynamic_skybox
after the $Skybox Model: line in the mission.
-
I'd like to revive this topic, cause the feature doesn't work anymore.
These flags don't work anymore when you add them to your mission.
+skybox_flags: ("MR_NO_GLOWMAPS")
+dynamic_skybox
Also it would be awesome, if the objects in the skybox could be lit by the sun/per-pixel light.
-
As far as I can tell the code was never committed. Bobboau only appears to have a handful of commits to missionparse.cpp and none of them were connected to this.
-
I remember taylor not liking that I used the same spelling as the model rendering tags and respelling the some time after it was committed.(point here being it was commited) I believe CVS was still being used at the time, is it possible that reverted commits were not carried over when everything was converted to SVN?
-
Before more people look for a solution, I think den5 has already solved the issue.
http://www.hard-light.net/forums/index.php/topic,60514.msg1192591.htm
-
I remember taylor not liking that I used the same spelling as the model rendering tags and respelling the some time after it was committed.(point here being it was commited) I believe CVS was still being used at the time, is it possible that reverted commits were not carried over when everything was converted to SVN?
I thought that it was committed as well, but I don't see it anywhere. I checked CVS, SVN, and all commit emails (since 2005) and don't see it ever having been committed. :confused: I do have a patch from your stuff that got reverted though, and it is in there. So I've got no clue why I can't find it anywhere else. I did go through that patch of reverted stuff and recommit some of it, and I thought this was one of those things, but I certainly don't see it in SVN.
If anyone wants the patch to go through and pick that code out then let me know and I'll send it to you.
-
I have one question.
Would this work with lighting now as well?
It would be really nice if I could slap normal maps on the rotating layers.
-
I think maybe. I seem to recall working on a rotateing planet model that had dynamic lighting, but that was years ago.
-
Now I really can't wait to get this feature back.
I already wrote down some ideas what this could be used for. And some of that stuff will look amazing. ;)