Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: Valathil on July 11, 2012, 12:38:42 pm
-
Ok so here's my deferred lighting implementation. I included an SSE2 Release build a patch file for the programmers and the required shader files. As usual you need to put them in the data/effects folder of your active mod to make it work. This version also includes Glowpoint lights but you have to modify your POF's to make it work. Example: in the Glowpoint bank properties edit field in addition to $glow_texture=blabla you can now write $glow_radius_multi=(float) which defines the light radius of the glowlights by multiplying each glowpoint radius of the bank by the multiplier and $glow_color=(red),(green),(blue) seperated by semicolons so the full string would look like : "$glow_texture=glow_yellow;$glow_radius_multi=15.2;$glow_color=255,255,0".
Have fun testing and please report all bugs and performance drops.
EDIT: We had a few issues with the Depth Buffer with ATI cards therefore this is now Beta 2 release. Debug build is included this time.
http://www.mediafire.com/?um9c1ukpq6684u6
EDIT: New Version look further ahead for link.
EDIT: Finally fixed ATI Artifacts look down for new BETA 4.
EDIT: New Workaround for ATI & NVIDIA compatibilty BETA 5 is released further down.
EDIT: Shadows & Deferred Combined Build now available! BETA 6 IS OUT!
-
Excellent.
-
Maybe I'm an idiot incapable of setting things right, but I see through ships and can fly thought them.
http://pastebin.com/yR6w2wML (http://pastebin.com/yR6w2wML)
Also screens:
(http://i45.tinypic.com/w7lhh.jpg)
(http://i46.tinypic.com/2rnef6x.jpg)
If you see what I mean.
-
Here (http://www.mediafire.com/?m8nb40w2qt21ckw) is an example Karuna pof with altered glowpoint properties for glowpoint lighting. Keep in mind that this pof will NOT work on any build that does not have glowpoint lighting. Don't let it hanging where it doesn't belong, like for example your BP2 folder.
It seems that the lighting doesn't follow the glowpoint itself when the glowpoint is attached to a rotating subsystem.
I tried to keep the effect visible yet subtle, in order to avoid what I call "the christmas tree effect". Will do more pof soon.
-
i think it follows in mission but not in lab. Cause lab has its own weird rotation code.
And Kobrar44 if you can fly through ships theres something really wrong cause i didnt change the collision code in the slightest.
I posted this on the main post as well but there is a new Beta out that fixes the ATI problems http://www.mediafire.com/?um9c1ukpq6684u6
-
So... I has question.
Although this is incredible, it may create some minor issues. Now obviously this doesnt force anyone to use glowpoints to make their lighting, but being able to cast glows on fighters as they fly through, say, the trenches of the Sathanas would be awesome,but here's the issue: The (unreleased...) sath already has baked glows all over it, and they look good. If I add glow points to the baked glow areas, then ships flying by would get a red glow on them, but it would also create a red glow along with the already baked red glows present, which could look wierd.
So the question: Is it possible to add a property or flag of some sort where the glow point would not light the ship it is attatched to? This way I can add the glow points to the sath without effecting its rather carefully orchestrated glow map, and still light up ships that pass by.
-
Simply put: no sry
-
Well damn.
-
integrating the shaders into the exe pokes holes in the whole reasoning for having shaders in the first place. having them outside the engine gives you the freedom to change the rendering styles within some degree. provided you are a graphics wizzard.
*edit* post i was commenting on has disapeared, odd.
-
Well, yeah, but this is only beta. I asked because I had a feeling like I put them in bad place. And I did.
-
integrating the shaders into the exe pokes holes in the whole reasoning for having shaders in the first place. having them outside the engine gives you the freedom to change the rendering styles within some degree. provided you are a graphics wizzard.
*edit* post i was commenting on has disapeared, odd.
the shaders are integrated into the exe for one simple reason. if you just run the binary with no mediavps and no mods it wouldn't work if there wouldn't be fallback integrated shaders.
-
integrating the shaders into the exe pokes holes in the whole reasoning for having shaders in the first place. having them outside the engine gives you the freedom to change the rendering styles within some degree. provided you are a graphics wizzard.
*edit* post i was commenting on has disapeared, odd.
It's a lot more complex than that. We're at a point where the gap between shaders and the EXE graphics code is becoming ever increasingly smaller. As the EXE begins to rely more and more upon shaders to do some really key calculations, the graphics code needs to be guaranteed that the shader code is doing what it should be doing. If submodel vertices are expected to be calculated on the vertex shader that needs to happen or else models will look wrong. If we're handing a bunch of g-buffers to the pixel shader, it needs to use that or else you won't get proper lighting. If we ever implement instancing, the shader needs to know about the per-instance data and the instanceID handed in by the OpenGL driver.
As me, Valathil, and everybody else who works on the graphics code continues to make progress on graphics features, we need to reserve the right to provide a baseline shader. And we'll do that by integrating the shader with the exe.
-
It's a lot more complex than that. We're at a point where the gap between shaders and the EXE graphics code is becoming ever increasingly smaller. As the EXE begins to rely more and more upon shaders to do some really key calculations, the graphics code needs to be guaranteed that the shader code is doing what it should be doing.
Will this change the FSO hardware requirements (namely supported OpenGL versions)?
-
integrating the shaders into the exe pokes holes in the whole reasoning for having shaders in the first place. having them outside the engine gives you the freedom to change the rendering styles within some degree. provided you are a graphics wizzard.
*edit* post i was commenting on has disapeared, odd.
the shaders are integrated into the exe for one simple reason. if you just run the binary with no mediavps and no mods it wouldn't work if there wouldn't be fallback integrated shaders.
but these are fallback shaders, correct? external shaders take precedence?
integrating the shaders into the exe pokes holes in the whole reasoning for having shaders in the first place. having them outside the engine gives you the freedom to change the rendering styles within some degree. provided you are a graphics wizzard.
*edit* post i was commenting on has disapeared, odd.
It's a lot more complex than that. We're at a point where the gap between shaders and the EXE graphics code is becoming ever increasingly smaller. As the EXE begins to rely more and more upon shaders to do some really key calculations, the graphics code needs to be guaranteed that the shader code is doing what it should be doing. If submodel vertices are expected to be calculated on the vertex shader that needs to happen or else models will look wrong. If we're handing a bunch of g-buffers to the pixel shader, it needs to use that or else you won't get proper lighting. If we ever implement instancing, the shader needs to know about the per-instance data and the instanceID handed in by the OpenGL driver.
As me, Valathil, and everybody else who works on the graphics code continues to make progress on graphics features, we need to reserve the right to provide a baseline shader. And we'll do that by integrating the shader with the exe.
im more intrested in the nuances of working without a fixed function pipeline, not for fs2 but for my other gl projects. so far ive mosly limited myself to fixed function pipelines in old skool gl. i havent ventured into shader land yet (probibly have to write a bunch of other code first, my c++ engine is still line drawn and needs a texture framework/loader and a better model parser, and my lua engine has all that but is limited to opengl 1.3 thanks to the luagl module im using).
-
Yes. The built-in shaders are loaded only when no external shaders can be found (although in the case of things like the video format conversion shader, there are no plans to ever make them editable).
-
Gave it a brief look, the weapon flyby lighting effects are neat
And once a capital ship jumps in, the whole area is basked in an eerie blue glow.
Havent looked at anything with glowpoints so far.
-
Anyone want to take some video of the coolness and post it?
-
Anyone want to take some video of the coolness and post it?
http://www.youtube.com/user/damaista/videos
-
This is so awesome! is there an option to control how strong the light is? seems strange that the lasers create an intense light reflection as beams...
does this mean missile explosions and flak will now have lighting turned on for them? Diaspora flak field would look amazing with this...
-
If you set laser color to be sth like 32 00 00, you'll get little light. I guess thats how it works.
-
Indeed. Light strength is defined through the light colour.
does this mean missile explosions and flak will now have lighting turned on for them? Diaspora flak field would look amazing with this...
Not sure what you mean here. If you're asking whether particles now react to lighting (as demonstrated in Battlefield 3's Frostbite engine), the answer is very definitely no.
-
I think he meant whether missile and flak explosions will produce light. They currently don't.
-
Well, in that case the answer is still "no, not at the moment". Right now, getting it to work correctly has to have priority over adding tons of new features.
EDIT:
MattThegeek has been hard at work turning the glowpoints on BP ships into light sources. This allows me to show off what this looks like.
Without lighting from glowpoints:
(http://blueplanet.fsmods.net/E/withoutgplighting.png)
With lighting from glowpoints:
(http://blueplanet.fsmods.net/E/withgplighting.png)
-
any chance at light emissions from glowmaps?
-
That would require image-based lighting so no, not yet.
-
Ok i converted the distortion rendering to do the depth test in the shader which should fix all ATI artifacts once and for all. I HOPE.
http://www.mediafire.com/?4po5m9n3pf0zdah (http://www.mediafire.com/?4po5m9n3pf0zdah)
-
Played around with it. Modded a Fenris's glows. Didn't see any problems, though I'm not sure what I was looking for beside animated glows throwing light.
ATI Radeon HD 4650
-
Well glowpoint lights are the only real new "feature" thing. There is not much visual difference in the game from the change. Actually that was the point. It's just that it works around the 8 light per ship limit that we had before. Theoretically there could be 256 lightsources near one ship and they would all be visible.
-
Played around with it. Modded a Fenris's glows. Didn't see any problems, though I'm not sure what I was looking for beside animated glows throwing light.
ATI Radeon HD 4650
just wait until they will enable lights on engine glows, missiles and flak explosions, and mods will start to light up their hangar bays with real lights(and shadows at one point) :)
*btw I just noticed the launcher flag of "apply lighting to missiles" doesn't actually do anything...
*funny little thing I noticed, the image with deferred lighting on has a higher FPS than the one without
-
just wait until [...] mods will start to light up their hangar bays with real lights
Done that on BP ships. Works like a charm.
btw I just noticed the launcher flag of "apply lighting to missiles" doesn't actually do anything...
I think it applies lighting to missiles. Which means missiles will receive light, not that they will emit light.
-
*funny little thing I noticed, the image with deferred lighting on has a higher FPS than the one without
Both images were taken on the same run, seconds apart. FPS fluctuations are not really relevant there.
-
Does that mean you activated the feature in-game?
*btw I just noticed the launcher flag of "apply lighting to missiles" doesn't actually do anything...
I thought this added that lens flare-looking effect to the missiles when they go farther away from your view.
-
No. I cheated and waited until the glowpoints were off, then took a screenshot. Those pics were meant to illustrate the differences (sometimes subtle, as on the Narayana, sometimes obvious, like on the Uriel) in appearance this stuff makes.
-
*funny little thing I noticed, the image with deferred lighting on has a higher FPS than the one without
Both images were taken on the same run, seconds apart. FPS fluctuations are not really relevant there.
well anyway its great to see this doesn't really affect FPS much if at all...
-
One thing i notice now that i think about it. The "apply lighting to missiles" flag is practically obsolete now cause lighting WILL get applied no matter what because they are solid polygons and therefore fall into the deferred pipeline. Only thing that would change is the application of static lights (suns).
-
depreciate another commandline flag FTW!
-
deprecate u mean.
Also thinking about spotlights and stuff. Easy Easy Easy. BUUUUUT... i do not know a good way how modelers would like to define them. I mean there's a lot of parameters to consider like spot direction and size, Is it rotating? If yes then how fast etc. I could just do it like before in the props edit field and maybe do direction by defining another glowpoint or something and linking that as a target but really i'd like to hear how modelers would think what the best way would be to define that stuff. DISCUSS!
-
i tend to prefer solutions that do not involve model editing, but thats just me. on the other hand the glow points system already has places for relevant data, and then there is the possibility to define the points in the modeling program. just get whoever codes pcs2 these days to make that props line a props box.
-
Personally, I believe the best solution to be to use a modelled, invisible-textured, noncollideable subobject. The light source would be the subobjects' centerpoint, with model properties being used to define light colour and attenuation.
-
Submodel centerpoint is probably not a good idea. Let's say you want to make a cone of light, you don't want your light source to be the center of the mesh, but rather the top of the cone.
Otherwise the idea is good. That way you can do whatever shape you want to accommodate the particularities of your ship. It's obviously harder to set up than glowpoint lights, but it's a much more elaborate effect so it's normal. And it's not any more difficulty to set up than modeled thrusters anyway.
-
I guess I was a bit unclear. What I called the "centerpoint" would be more accurately described as the pivot point, which is a property that can be set and manipulated in a modelling program.
-
My mistake. I had automatically mistranslated with "bounding box centerpoint".
-
won't it be easier to simply edit invisible glow points? one for position and starting radius, and the second for projection direction and end radius... its better to leave these things for PCS2 IMO
-
Won't give you shapes different from truncated cones. And E's option would be just as easy as setting up modeled thrusters, from what I understood. Even easier since the mesh doesn't have to be UV'd.
-
Umm, okay, think I found an artifact.
I cant get a clear shot but if you zoom in, you can see a pixellated white light when the Cruiser is shot by lasers. Its quite noticeable in-game.
e: using HD 5770 (ATi)
e2: using the beta3
[attachment deleted by a ninja]
-
i dont see it.
Also on the topic of meshes. You WILL only be able to define cone lights mesh defined light ranges will not be possible.
-
Right. Then something along the lines of Nighteyes's idea might be more convenient.
-
This is probably more visible:
[attachment deleted by a ninja]
-
WHAAAAAAT THEEEEEE FUUUUUUUUUUUUUUUUUUUUUUUUUUCK
-
heres the thing. the glow point chunk stored in the model allows you to set the following:
displacement time (float)
on time (float)
off time (float)
parent subobject (int?)
lod (int?)
type (int)
properties (n-length string)
and an n-element array (for each point) of
position (vector)
normal (vector)
radius (float)
now the type field was originally used to define 0=points, 1=beams. this being an int value can have many other values. i was kind of disapointed that other glowpoint styles had not been defined. what you can do is maybe 2 = point light emission source, 3 = conic emission, or 4 = light shaft. im assuming this is an 8-bit int, but if its a 16 bit int you might allocate the msb to emission type, and use the lsb for glow-point type meaning any glowpoint could have any emission type. the structure would be essentially the same. if the value of 0 is no light emission, then it would be reverse compatible with older models. the only data the system really lacks is a place to put a color value. you can stick that in properties.
another (less hackish) idea is you set up a table for glowpoints, which defines bitmap used, how bitmaps are rendered, what kind of light emission is used, what color is the emission, other effects like flickering or color ramping effects, etc. everything but where it is, where it points, and how big it is (which is defined by the glow point chunk). you can then reference a glowpoint table entry with the type field (though it may be more intuitive to add a tag to the properties string to specify an entry by name instead). the default table would only specify the first to entries taken up by type 0 and 1. if you override these with a new table you could enable light emissions from existing glowpoint types without model tweaks! and if thats not enough you can always define new glowpoint types in the table.
actually now that i think of it the latter paragraph sounds like the better idea, its less hackish and lets us use the feature immediately with a small table and without major model surgery. i would also open this up to scripting so that script defined lighting effects could be done.
-
The table thing was my first idea when i was implementing it too but then i found out its not possible to uniquely identify glowpoint banks other than by the order they are in the model. I mean if we say
$Model: blabal.pof
$BankNum: 1
Properties....
$BankNum: 2
...
etc we could do it but same problem with the direction of the spotlights. i mean if you guys would be alright with defining it as a vector in model space i can do that. it just feels kinda of user or modeler unfriendly. Best thing of course would be an upgrade to pcs2 where you can actually do spotlights in the thing and do all the direction angle and radius stuff in pcs2 with a rendered wireframe cone so you can see the thing and everything. I dont know how possible that would be tho.
EDIT: also how would individual glowpoints(lights) be handled it adds another level of non identifyability (without going to the index number again) to this problem
-
i was thinking more of doing that in reverse. glowpoints remain the same, the contents of the table is more for lighting presets. sort of like
$glowpoint preset: Shivan Glowy thing
+bitmap: some.bmp
+type: point ;spot ;shaft ;etc
+light color: 255 0 0
...
this would be a global table and goes somewhere relevant. probibly not in the ships table because you could use them for weapons and other models as well. then in your glowpoint properties you have:
$use preset: Shivan Glowey Thing
where the position, size, direction come from the glowpoint in the array. the actual indices are hidden from the user. and you dont have to deal with a bunch of vectors in the table either (autogen ftw), just what the lighting effect looks like. if you need to use more than one preset then you need to create a glowpoint banks for each one of those. if you have a bunch of identical glowpoints, you can just throw em all into one bank. as for object space vectors, modders have to deal with them on a regular basis anyway, so i really dont mind that.
-
Hmm, I like this idea. Less resaving POFs every time you want to tweak a glowpoint light.
-
Hmm that sounds good yeah. So make a glowpoint.tbl and throw all the stuff in there. Sounds resonably simple. I'll try to whip up something in a few days i'm currently working on shadows again cause ATI is really starting to piss me off with the artifacts cause I CANT ****ING DEBUG IT ON MY OWN cause I don't have an ATI card and im not in the right sleep cycle to work together with Swifty or The_E.
-
So basically, if I understand correctly, we would not put stuff in the glowpoint properties anymore, but we would change the Type field to point to an index in a table that has all the required info ?
-
Just curious: how big are the differences between how ATi and nVidia handle opengl? It seems that half the great stuff you put out can't be run properly by ATI hardware.
-
I don't know exactly what is the problem with ATI. EITHER they take the OpenGL spec TO THE LETTER and NVIDIA is more lax and do some extra error prevention stuff and i do some things wrong OR they are the lax ones and cause errors by that. Also in part is because i dont develop on ATI hardware, maybe if it was the other way round ATI would be fine and i get tons of problems on NVIDIA hardware who knows.
(http://images.bit-tech.net/content_images/2005/03/interview_nvidia_dev/twimtbp.jpg)
This is for The_E: http://www.mediafire.com/?sub1zf0wjo98i8o he knows what to do.
-
I've done a short test and it looks amazing. Any plans to extend the effect to ship (and maybe even missile) thrusters?
-
Features will be added once whole thing works correctly.
-
For ship thrusters, nothing prevents you tu put an invisible glowpoint there.
...which means you've got to link it to the engine submodel so it doesn't keep emitting after the ship is disabled. If the ship actually has submodels for its engines. Yeah.
-
Well, that's, of course, one of the solutions, but it's hackish and not very comfortable (not to mention it doesn't work if there are no engine submodels, nor does the intensity vary with the amount of thrust). While we're at it, this would also be a nice feature for RCS thrusters, though it shouldn't be on by default on them (the most common RCS effect looks like a white gas poof, which doesn't look like it'd emit any light).
That's, of course, a suggestion for much later though.
-
i would presume you could use the glowpoint properties to add an $engine subsystem: tag for linking the effect to engines. you could presumably define more complex effects in the glowpoint table as well. like light ramping or color varience. if the coders felt like doing something like that. doing a table does give you places to put new tags for new features which may be added in later on.
-
just a head ups for people that currently toying around with the glowpoint properties. The current syntax will be deprecated in favour of the table format we discussed earlier so if you are currently working on that you might want to focus on something else till the format specification is finished.
Also thanks to The_E's help I could finally fix the ATI artifacts. IT WAS ATI'S FAULT btw. They have a bug in one of their extensions that has gone unfixed for 3 or more years.
So without more delay http://www.mediafire.com/?765smic3zbygezh BETA 4.
-
(http://i97.photobucket.com/albums/l223/SpootKnight/FreeSpace/th_Lighting4.png) (http://s97.photobucket.com/albums/l223/SpootKnight/FreeSpace/?action=view¤t=Lighting4.png)
(http://i97.photobucket.com/albums/l223/SpootKnight/FreeSpace/th_Lighting43.png) (http://s97.photobucket.com/albums/l223/SpootKnight/FreeSpace/?action=view¤t=Lighting43.png)
Here's what I'm running into with the 5870 running 12.4 drivers. I'm about to try this with 12.6 and see if anything different happens.
No effect to my unsurprise.
-
That's easily fixed.
EDIT: What you (Valathil) need to do is, change gr_opengl_copy_effect_texture to this:
void gr_opengl_copy_effect_texture()
{
if ( !Scene_framebuffer_in_frame ) {
return;
}
glReadBuffer(GL_COLOR_ATTACHMENT0_EXT);
glDrawBuffer(GL_COLOR_ATTACHMENT4_EXT);
vglBlitFramebuffer(0, 0, gr_screen.max_w, gr_screen.max_h, 0, 0, gr_screen.max_w, gr_screen.max_h, GL_COLOR_BUFFER_BIT, GL_NEAREST);
glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
glReadBuffer(GL_NONE);
}
-
I'm using an NVIDIA Geforce 9800 GT, and when I'm in the middle of playing The Sixth Wonder (specially, when I'm trying to shoot down a bomb), I get this error
Assert: Scene_depth_texture != 0
File: gropengldraw.cpp
Line: 1426
<no module>! KiFastSystemCallRet
<no module>! WaitForSingleObject + 18 bytes
<no module>! <no symbol>
<no module>! <no symbol>
<no module>! <no symbol>
<no module>! <no symbol>
<no module>! <no symbol>
<no module>! <no symbol>
<no module>! <no symbol>
<no module>! <no symbol>
<no module>! <no symbol>
<no module>! <no symbol>
<no module>! <no symbol>
<no module>! <no symbol>
<no module>! <no symbol>
<no module>! <no symbol>
<no module>! RegisterWaitForInputIdle + 73 bytes
The fs2_open.log is attached.
I haven't tested beta 3, but I know that beta 2 worked just fine for me.
[attachment deleted by a ninja]
-
ok now nvidia is the screwed one cause they dont support the seperate depth stencil buffers that are required to get ati to work which is great. i need more testing of the ati thing maybe i can do seperate initializations based on the vendor string or something
EDIT: Ok i got a workaround BETA 5: http://www.mediafire.com/?nnn9mbal5c5si2p
-
I noticed that in this build(Beta 5), targeting the nearets enemy doesn't seem to work most of the time. Other ways, like targeting the newest ship in the battle works fine. Only other problem I've noticed is that in the tech room, thruster points shine through the ship model.
-
So, how's the glowpoint table coming along?
-
Srsly? You've seen Valathil posting the Shadows beta builds? How many things to expect him to literally work on at once?
-
He's obviously been working mostly on shadows, but maybe he made some progress on glowpoints too. I'm asking, because there's a few models I need to glowpoint, but I don't feel like using a syntax which is planned to be deprecated before I even start. Besides, you never know with Valathil. :)
-
Don't you worry, I have already made clear that I was going to adapt the whole MVPs' glowpoints once the glowpoint.tbl is complete, and I make sure to regularly remind Valathil about it.
-
He's obviously been working mostly on shadows, but maybe he made some progress on glowpoints too. I'm asking, because there's a few models I need to glowpoint, but I don't feel like using a syntax which is planned to be deprecated before I even start. Besides, you never know with Valathil. :)
you can glowpoint them now without problem. As said the glowpoint.tbl thing will work without modifying existing models. you just have to postpone the lights definition for later. Also im interested in you guys coming up with a format for the table since you guys will be the ones using it so write up a spec or sample of what youd like to see and ill think about it and we can discuss.
-
Wait, completely no model changes? That could come out clunky and hard to use. I thought you'll use glowpoint types.
As for the format, I'd like something like:
$Type:
$Index: (which glowpoint type number we're talking about)
$Thruster Bitmap: (used instead or in addition to index, name of the thruster bitmap that, when used either in the "main" or tabled "maneuvering" thruster will emit this kind of light)
$Color: (self explanatory, 3 values RGB. 3 zeros disable the light. If absent, the color will be based on bitmap's histogram)
$Alpha: (bitmap transparency percentage, setting it to 100 disables the bitmap completely)
$Intensity: (light intensity, gives finer control than color)
$Light Cone: (number of degrees from the normal the light will be radiated)
$Bitmap Cone: (number of degrees from the normal the bitmap is fully visible)
$Flags: ( "No Self Lighting" "No Obscuring" "No Flicker" "Start Off" ) (the first one disables the glowpoint casting light on it's parent model, the second one causes the glowpoint to be rendered on top of the model, the third one disables flickering when the ship is damaged and the last one makes the glowpoint off by default, to be enabled in FRED)
That should be it I think.
-
Please no... bleh..
I'll whip up something that makes much more sense later.
Wait, completely no model changes? That could come out clunky and hard to use. I thought you'll use glowpoint types.
Srsly? :wtf:
This table is to define the types... Certainly not as clunky as putting all that data in the POF itself.
-
Would you mind using the {code}{/code} bb tags, as well as indent items that are a sub-item of the one above it?
I don't know about Valathil, but it's much easier for me to implement new .tbl items when I see them in the same format as they would appear in the .tbl itself. :yes:
-
Srsly? :wtf:
This table is to define the types... Certainly not as clunky as putting all that data in the POF itself.
The way he said it made me think that everything will be table defined, referencing the model and glowpoint bank from it. Doing it like that (on a per-ship basis) would be clunky. If table will be used for defining the types, then it'll be good.
-
...Only other problem I've noticed is that in the tech room, thruster points shine through the ship model.
Slightly off topic, but this is a separate bug that has been fixed in trunk already.
-
i was basically thinking of doing it like you define the types First and then do a list of Ships where you can say this glowpoint(s) Bank light(s) are this Type. and Support multiples in the selection Like (1,3-4) would select 1 3 and 4 and assigns them the preset. if you want to edit models to Do a Type Tag more than my proposed solution. please tell me and include a reason why that would be a better view if backwards compatibility is taken into account
-
Backwards compatibility is fine, and I think your idea would be good, but alongside being able to just assign the type in a model. It'd take a lot less work to make a minor model edit than to maintain a table segment with yet another list of all ships in the mod.
-
Nah, all-table is good, forget the pof edits. We don't want to have to maintain two ways of doing the exact same thing now do we.
Also, I don't think you understood Vala's idea. He isn't going to make us list all the ships in glowpoint.tbl, but select the glowpoint type with a table entry in ships.tbl, then define that type in glowpoint.tbl.
Vala, we should probably discuss it on IRC further before you lay down the final implementation, to make sure all parties involved are cool with it.
-
I don't like the all table idea. I also don't like having yet another field in Ships.tbl, while we have everything already in place for managing glowpoint types from the POF. All table is more trouble than it's worth, though it might be fine as an override, should anyone need this. Also, if you've got a lot of types and a lot of glowpoint banks, this would clutter up ships.tbl way too much.
-
Speak for yourself. Personally, I think that doing as many things as possible in a table is preferable to model edits, since model format changes are more of a nightmare than table changes.
-
The thing is, we're not changing model format this time. Glowpoint type is already in, and can be set to whatever value you wish. Only 0 and 1 actually do something now, but with glowpoints.tbl, this could change. Since the value is there, FSO could simply read it and make the glowpoint bank behave accordingly. This should be simpler than messing around with ships.tbl.
BTW, one more thing. What's the deal with type 1 glowpoints? I could never quite figure out how exactly they work.
-
Could you just, please, listen to the advice from the very people who are actually familiar with the code ? I do not think you are more qualified than they are for this kind of matters.
-
The thing is, we're not changing model format this time. Glowpoint type is already in, and can be set to whatever value you wish. Only 0 and 1 actually do something now, but with glowpoints.tbl, this could change. Since the value is there, FSO could simply read it and make the glowpoint bank behave accordingly. This should be simpler than messing around with ships.tbl.
BTW, one more thing. What's the deal with type 1 glowpoints? I could never quite figure out how exactly they work.
What is the advantage of specifying the glowpoint type on the model itself vs. in a .tbl?
-
The way I see it, specifying it in a table is preferable since it allows different light configurations for different ships using the same base model (Actually, I would prefer glowpoint banks to be completely specifiable in the ships.tbl, since editing GP settings in PCS2 is a royal pain in the arse for complex setups).
It's just a general preference, really. I would prefer for model files to be _only_ model geometry definitions, and using the tbl to specify all the other things; the way FSO splits ship definitions between data in the model and data in the tbl is a bit awkward, really.
-
POFs are not modular, Tables are. Bam. Done.
-
I've done a lot of glowpoints and I can tell you that putting them into the table would be really, really annoying. You wouldn't be able to manually fine-tune it's position and radius, you'd have to make do with a subsystem dummy to get it right. And even then, you'd have to guess the normal. I already have this problem with maneuvering thrusters and trails (especially the former). If glowpoints were tabled, I couldn't drag them around, adjust radius with the mousewheel and roughly imagine how the ship's going to look with them (if you didn't know that's possible, try it. Just hold ctrl in PCS2 and have fun with pinpoint positioning). Unless Spicious links TBL editing to PCS2, I'm against moving anything to the table. I most likely wouldn't have had patience to do things like intrasystem gate from WiH or any kind of "running" runway lights if it weren't for PCS2 making it easy to copy glowpoints and move them around.
And as I mentioned, the entire functionality required for this is already sitting there in the model format, almost completely unused. I don't believe it's harder to read a single number from a POF file than to write an entirely new Ships.tbl setting. And who would want multiple glowpoint setups with a single model? These are usually made to precisely fit with a model geometry and textures. I don't see any reason to change lights between mods.
-
I've done a lot of glowpoints and I can tell you that putting them into the table would be really, really annoying. You wouldn't be able to manually fine-tune it's position and radius, you'd have to make do with a subsystem dummy to get it right. And even then, you'd have to guess the normal.
What do you mean "Guess the normal?" 3D Max has the ability to tell you what the angle of the centerpoint of the object/dummy or whatever. I'm very certain Blender is capable of this, too.
Also, PCS2 allows you to type in the XYZ coordinates of glowpoints and thrusters, am I right? What's wrong with writing down the coordinates of your dummy object in 3DS Max/Blender/whatever and then typing them in PCS2?
-
So Dragon is saying he prefers WYSIWYG and everyone else wants to edit their HTML in Notepad? Why not link PCS2 and table editing, then?
What do you mean "Guess the normal?" 3D Max has the ability to tell you what the angle of the centerpoint of the object/dummy or whatever. I'm very certain Blender is capable of this, too.
Also, PCS2 allows you to type in the XYZ coordinates of glowpoints and thrusters, am I right? What's wrong with writing down the coordinates of your dummy object in 3DS Max/Blender/whatever and then typing them in PCS2?
From an outsider's perspective, that just sounds like 300% extra effort and so much more of a PITA than click and drag.
Dragon, can you give a detailed step-by-step walkthrough of what you would have to do to glowpoint / change the glowpoints on a model with the way you want things done, and then the way they want it done? Maybe then a solution will be brought forward that everyone will find livable.
-
you dont do the glowpoints in the table you still do them in the model the only thing you do in the table is THE LIGHTSOURCE the glowpoint creates i think theres a misunderstanding on that part by some readers here.
-
So Dragon is saying he prefers WYSIWYG and everyone else wants to edit their HTML in Notepad? Why not link PCS2 and table editing, then?
Not a bad idea, by the way, it could be rather useful, but PCS2 would have to be updated a lot more often. A few more improvements, like being able to display thruster and glowpoint bitmaps, trails and maneuvering thrusters could make more than a few lives much easier. But I doubt that's gonna happen.
What do you mean "Guess the normal?" 3D Max has the ability to tell you what the angle of the centerpoint of the object/dummy or whatever. I'm very certain Blender is capable of this, too.
Also, PCS2 allows you to type in the XYZ coordinates of glowpoints and thrusters, am I right? What's wrong with writing down the coordinates of your dummy object in 3DS Max/Blender/whatever and then typing them in PCS2?
From an outsider's perspective, that just sounds like 300% extra effort and so much more of a PITA than click and drag.
Precisely. Intrasystem Gate from WiH, one of my personal best, has 27 banks, 18 of them with two glowpoints, the rest with many more. Tabling this would literally take all day. Not to mention I'm not spending 1200$ for a 3DS max, nor learning Blender and it's arcane interface and shortcuts to do what I do in PCS2 with mouse.
Dragon, can you give a detailed step-by-step walkthrough of what you would have to do to glowpoint / change the glowpoints on a model with the way you want things done, and then the way they want it done? Maybe then a solution will be brought forward that everyone will find livable.
Let's assume we have a new glowpoint config under index "2".
My way:
Open up a model.
Go to "glowpoints" tab, change the "type" field to 2 for each bank.
Save the model.
Practical note: With practice, this is the sort of thing you can do extremely fast. You don't move your keyboard finger, only mouse and you do it in a single pattern. This is menial, but not annoying, and there's no room for error, you always get it right first time. Even if you've got multiple types to assign, it's not much slower, even if you get into double digits.
Now, the table way (as mentioned here: http://www.hard-light.net/forums/index.php?topic=81376.msg1632792#msg1632792):
Open up the model for reference (well, not necessary in this example, but in more complicated operations you need it).
Open up ships.tbl .
Write the ships.tbl field name.
Write "2", then a string of numbers equal to the number of glowpoint banks on a ship (in case of the intrasystem gate, you'll be typing all numbers from 1 to 27).
Save the table.
(im)Practical note: This means manually typing a lot of numbers. The more types you have, the more of this you have to write, with eventual parentheses, commas and whatever. Not to mention it doesn't quit have the "dynamic" (you look at the bank in PCS2, think "I want a type 4 here" and change immediately that without switching from PCS2 to table), and you have to count the banks manually in order to make out which is which, as PCS2 doesn't display the numbers next to them.
Comparison: Let's take the gate, and let's say you have 27 lighting presets (this is an exaggerated example, but gets the point across).
In my way, you type 27 numbers directly in the model, nothing more.
In tabled way, you type something like "(1-1, 1-2,... ...27-27)", along with all the syntax stuff. And if you skip a separator, a comma or whatever you have to look at this unwieldy string and search for a typo. Twice as many numbers, a lot more work.
Now, this might not seem like a big deal, and I might seem like I'm making much ado about nothing, and exaggerating too much to get the point across. But keep in mind that I'm going to be implementing this for two entire fleets in WiH, many of them have enormous glowpoint counts (I know, I did them). And not only that, I'll have to make sure this looks good, and will most likely add some more points. It suddenly accumulates a great deal of work.
you dont do the glowpoints in the table you still do them in the model the only thing you do in the table is THE LIGHTSOURCE the glowpoint creates i think theres a misunderstanding on that part by some readers here.
I know you don't intend to change glowpoints themselves, I was just pointing out how impractical table-based points are. However, assigning the lightsource should also be done in model, via "type" field.
-
ASFGHJKL; NO.
No more POF-side things, goddammit.
Just copy coordinates from PCS2 into the tables (and flip their x-values because whoever designed the coordinate system of one of them is retarded I won't point fingers).
Typing Numbers >>>>>>>>>>>>> Clicking several times with a mouse. Seriously, if your goal is to get things done and not to get carpal tunnel, type >>> click.
PCS2's, while powerful and convenient, has (frankly), a **** interface in terms of click registration/drop down menu stuff, and is really finnick and keeps forgetting **** and is rather buggy. This is coming from the guy that advocates you doing all your non-hierarchy rigging in PCS2 instead of setting up fire points etc. in max (even if I have it). IF I could do all those things tableside I would so ****ing do it. Notepad best modding program hands down.
-
Just copy coordinates from PCS2 into the tables (and flip their x-values because whoever designed the coordinate system of one of them is retarded I won't point fingers).
This is one of the most annoying things about maneuvering thrusters. Tell me how you'd do this 80 times without going crazy. Regardless, this won't be done in tables anyway.
I don't know what mouse you're using, but I prefer clicking to typing a row of numbers you can't even copypaste.
-
So, we've talked about this on IRC, and we came to the conclusion that what we want to do is this:
1. Implement a glowpoint.tbl. This would be used to define glowpoint types, which hold data such as texture, blink rate, size, plus all the parameters the new lighting engine would allow.
2. In ships.tbl, settings will be added to allow the tabler to assign a glowpoint type to each bank. If a glowpoint type is set, the data from the GP type will override the settings in the model (this will preserve backwards compatibility)
-
reason being that only this setup can support multiple ships with the same model but different glowpoint configurations without duplicating models. And we think that having different configurations for the same model is a feature we would like to have.
-
So in the end, we basically arrived at my initial suggestion of having the table as an override to types defined in the model. I guess that's an optimal solution.
-
Happy Bilbo is happy the wizards at the wizard table are happy.
-
:wtf:
Looks to me like the glowpoint stuff in the POF stays the same. If you want new glowpoint features, you'll need to use the table in addition.
-
Just copy coordinates from PCS2 into the tables (and flip their x-values because whoever designed the coordinate system of one of them is retarded I won't point fingers).
This is one of the most annoying things about maneuvering thrusters. Tell me how you'd do this 80 times without going crazy. Regardless, this won't be done in tables anyway.
I don't know what mouse you're using, but I prefer clicking to typing a row of numbers you can't even copypaste.
I don't know what keyboard you're using if you can't copy paste and delete a negative sign....but hey.
Also I did do that for the persistent trails for all fighters in DE (copy the thruster point coord, paste into table, change :'s to spaces...really. easy.)
But whatever this is a moot point.
reason being that only this setup can support multiple ships with the same model but different glowpoint configurations without duplicating models. And we think that having different configurations for the same model is a feature we would like to have.
This is cool
-
If you're stuck using the keyboard, it's best to quickly pick up all appropriate shortcuts. To whit,
Shift + arrow keys = select one char at a time
Shift + Ctrl + arrow keys = select one word at a time (it uses spaces to detect words, so not always useful)
Shift + End / Shift + Home = select from cursor position to end of current line or beginning of current line
Ctrl + arrow keys = move cursor one word at a time
End / Home = move cursor to end of line / beginning of line
Ctrl + Backspace / Ctrl + Del = delete entire word before / after cursor position
Click + hold Shift + Click = select from first click thru second click
Ctrl + Click = select / deselect individual entries (can be used for great win in combination with Shift-clicking, e.g., I want from here thru here except these two)
Ctrl + X, C, V = Cut, Copy, or Paste the currently selected items
Alt+Spacebar = bring up program menu in the top left (yeah the one that you used to be able to get in Windows 3.1 by clicking the - sign on the top left)
Alt+Spacebar+M = select the move option from the program menu, allowing you to then use the arrow keys (or mouse) to place your window on the screen. Especially useful if your program opened up off-screen for whatever reason.
Alt+F = File menu. add S to save, A to save as, C to close, O to open
Alt+E or V, etc.. opens Edit, View, etc...
Note that I typed all of that up from memory, and there's a million other shortcuts out there, many of which I regularly use without thinking. The only thing the mouse can do that comes close is gestures, and that's only just beginning to be widely supported IIRC... except the Macs may have had it for a while. But it still can't touch a keyboard, only add to the keyboard's awesomeness.
Not that I'm disputing that this is still a PITA, but with shortcuts it's a rather manageable pain in the ass...
For example, I once had to save a few hundred .TIFF clipart files on an old system 8 or 9 Mac as a different type of TIFF that was compatible with the MS software my dad was using. I wasn't aware of any batch method of doing this, so I did it all by hand. It took me between half an hour to an hour, but it probably would have taken an average user the better part of a day. Why? Keyboard shortcuts. Alt+F+O, down arrow to next file, enter, Alt+F+A, press the appropriate combo to change filetype (I believe Alt+T, down arrow), then Alt+A, home, to add a prefix to the filename (new_ or somesuch), press enter, rinse, repeat.
After the first 20 or so, you begin to take ~3 seconds max to get this done, as you've developed a routine. You could probably go faster, but you do need to be sure not to make mistakes whilst processing.
The same approach, when taken with editing tedious text-based config files, will cut down your workload immensely. Although it will still be a PITA. :ick:
I'm assuming the reason you still wish for mouse control is that there's no way to have a live preview of the changes you are making, and no way to precisely place an object where you want it by simply giving raw coordinates, unless you're just a genius, or copying from something else that's in approximately the same location as the object that you are placing.
Any way to edit the appropriate table files from within a preview application in a notepad-esque window? i.e., open the file, see the model and everything on it, decide you want to edit the glowpoints, tell the app to do so, get a notepad window, and fudge with the numbers, whilst getting a live output? How about the ability to copy a coord to the clipboard when clicked by the mouse? You'd need a way to orient which way the coord is "facing" so to speak, but that'd be a charm..
Pipe dream? Yeah, I figured. :doubt:
-
I don't know what keyboard you're using if you can't copy paste and delete a negative sign....but hey.
Also I did do that for the persistent trails for all fighters in DE (copy the thruster point coord, paste into table, change :'s to spaces...really. easy.)
It's not that I can't do it (it's the only way of precisely positioning maneuvering thrusters), but compared to doing everything in the POF, it's unnecessarily lengthy. Once again, the task in itself is not an issue, the problem is the number of times you need to do it. 5-6 times for thrusters is perfectly fine, but if you make very complex glowpoint schemes, you're going to be placing at least 50 of them. Can you imagine copypasting 50 sets of coords into a table? And you still need to click to switch between programs and select the place where to paste the coords. And replace colons with commas. This all adds up. I've done a task on similar (though smaller, in 20s) scale, with the aforementioned tabled thrusters (I thought it was worth it until Steve-O started remaking his fighters...), so I know.
-
What in the actual hell.
no one said you'd have to place your glow points via coords in a table. the table is just for defining what your glow point does... unless I've missed something somewhere.
so relax please.
-
Well I was saying how I wouldn't mind doing that at all.
-
Will there be option to make particular glowpoints use whiteout effect? Some strong lights sources should have it.
-
Oh please not. Models are there to be seen, not to white out the screen.
-
If you don't know how to use such a feature, yes, this is probably what you'd get. With proper controlling options this would give a nice and realistic effect.
-
REALISM ? IN MAH FREESPACE ?
-
If you don't know how to use such a feature, yes, this is probably what you'd get. With proper controlling options this would give a nice and realistic effect.
As I see it, there are ways to use this properly, mostly in cinematics. And in those cases, what you really need is scripting, and for scripting to have access to the new lighting system. I don't see how this would be anything but a nuisance during actual gameplay.
-
AND LENSFLARES DONT FORGET LENSFLARES
-
AND LENSFLARES DONT FORGET LENSFLARES
Hey, a good lens flare effect for beam cannons would be pretty cool, as would a fake HDR effect that darkens everything but the beam when you're close to it.
-
AND LENSFLARES DONT FORGET LENSFLARES
Hey, a good lens flare effect for beam cannons would be pretty cool, as would a fake HDR effect that darkens everything but the beam when you're close to it.
Agreed!
-
Then get to coding.
-
Too busy making my own game that doesn't involve codethulu. Sorry, I'll leave the code equivalent of the ninth circle of hell to you guys.
-
too bad everyone keeps turning down proper lens flare support because they are afraid it might be misused.... /stupid argument
-
if you can get me the way how they do those new fancy camera convolution kernel lensflares like they doing in cryengine3 and unrealengine4 we could talk about that i think.
-
Leave it to the wizard ;7
-
if you can get me the way how they do those new fancy camera convolution kernel lensflares like they doing in cryengine3 and unrealengine4 we could talk about that i think.
Here you go. It's not actually new, but it's really hard on older GPUs so it wasn't ever implemented until now. Anything lower than a 9800GTX categorically can't handle it at a playable framerate.
http://nae-lab.org/~kaki/paper/PG2004/Kakimoto2004GlarePresen.pdf
http://www.mpi-inf.mpg.de/~ritschel/Papers/TemporalGlare.pdf
-
Thats a prestep of i what was talking about but is still based on single lightsources being the source of the flares. I'm talking about the new screenspace **** where you get multipath reflections in the camera lens and prisms.
-
Oh, that can be faked in all sorts of ways. What manner of accuracy/realism would you want to go for? The quick and dirty ways look pretty good and are comparatively cheaper (for example, you give the shader a preset texture with the camera flare textures and a HDR map (or if you want to get fancy, a Z buffer as well), then use a lookup to the other side of the HDRmap/depthmap to see where to reveal/transform the texture and/or draw flare bits) but the really accurate ways are worse than (and definitely related to) Bokeh calculations on DOF.
I assumed you wanted something else because the pilot's POV is usually an eyeball, not a camera lens. Anyway the method I showed you doesn't only use points as flare sources; there are examples of entire stained glass windows or a close-up candle flame showing larger, shaped, complex flares. The primary input to the shader would be a full RGB texture.
-
im partial to seperating cockpit view lensflares and external camera flares and use two different algorithms so youll actually see a difference
-
All you'd really have to do is change the shape of the eyeball filters used in the shader and change up some of the math, and add some way to offset the various steps in space so you can see them telescoping out rather than overlapping. If you can write the shader in the 2nd paper (it's based on the 1st paper) you can then modify it for camera lenses.
This is probably the best solution I can think of. I'm not an expert but I have programmed graphics engines before, so I probably have a better idea than most on this forum.
-
I would wish for a pure screenspace effect no additional geometry needed.
-
You have to supply some sort of static filters to the shader to use for the camera/eyeball effects to create their shapes and properties. What I meant between having different filters for eyeball and camera is basically just having two shaders that a SEXP can switch between, one that simulates an eye and another that simulates a camera. I don't think the papers I posted require anything beyond some precomputed (read: STATIC) eyeball/camera data and a HDR texture (containing the bright stuff like beams) to make the effect. The whole shader could be made with two parameters if you were so inclined.
However, like the Bokeh effect, you may find that taking load off of the shader and passing it more to the CPU (i.e. rendering sprites the old fashioned way) actually improves performance. The fastest implementation of the Bokeh DOF is to use a shader for the gaussian blur and then overlay polygonal sprites on bright points. It's much faster than a per-pixel convolution overtop the entire scene, which a completely-GPU-bound Bokeh effect would need.
You could render to a float target to begin with and not have a separate HDR map at all; just render the beam at a luminosity higher than everything else in the scene. However I have no idea how the renderer is set up, only that you recently changed it to be unified under a G-buffer.
-
First draft of glowpoint.tbl https://docs.google.com/document/d/1Q736btTmHytE9FAPsV_QkZ_8WJk7vIbIt_zvGiiKYnA/edit
-
Those are per-bank overrides, what about types? I don't see any value for overriding the glowpoint type either. Also, what $Name: is for?
-
$Name is for identification of the preset so you can assign it to banks in the ship.tbl.
Is Type Override really needed? I never saw anybody use Type 1 glowpoints but i guess it could be added for completion sake.
-
So, does this means you're not going to use glowpoint types afterall? I wanted to be able to assign the presets in POF using that value. That's the unused value in POF data I've been talking about all the time. In fact, this syntax would more or less work for a type definition, just add an option to replace $Name with $Type, or maybe even use them together for a multipurpose preset. The priority order would go: POF data -> Type Definition -> Override. In short, you're able to assign presets in a model as well as in a table, but the table would override the POF data.
The point is to allow a modder to make model glowpoints act more or less consistently across multiple mods, as long as they follow some common layout of glowpoints.tbl (as with most things, a glowpoints.tbl from mediavps will most likely become such a "convention").
Also, would that be possible not to remove the old, model-based syntax? The reason is pretty much the same as above (well, that, and it seems that BP added this syntax to every single glowpoint bank on every ship bigger than a bomber, making changing them back a bit of a chore :)).
-
Also, would that be possible not to remove the old, model-based syntax? The reason is pretty much the same as above (well, that, and it seems that BP added this syntax to every single glowpoint bank on every ship bigger than a bomber, making changing them back a bit of a chore ).
What has been committed in can be reverted out. I vote for a complete removal of the old way.
-
Also, would that be possible not to remove the old, model-based syntax? The reason is pretty much the same as above (well, that, and it seems that BP added this syntax to every single glowpoint bank on every ship bigger than a bomber, making changing them back a bit of a chore ).
What has been committed in can be reverted out. I vote for a complete removal of the old way.
Agreed. The proposed table looks good to me.
-
I hate to seem like I'm trying to wiggle in a feature request, but while we're talking about glowpoints, with all of these changes, can we also have glowpoints be able to fade in and out as they turn on and off instead of being completely binary?
If that's a feature for another day, then so be it.
-
I hate to seem like I'm trying to wiggle in a feature request, but while we're talking about glowpoints, with all of these changes, can we also have glowpoints be able to fade in and out as they turn on and off instead of being completely binary?
If that's a feature for another day, then so be it.
Dang, now I'm picturing one of those creepy radio tower red fading lights in the fog. Could do some really atmospheric stuff with fading glowpoints.
-
Oh yes... I'd love this for the HTL Comm Node.
-
You're supposed to be alone in the nebula and then the glowpoints of some massive warship slowly fade in. It doesn't show up on sensors, and your ship can't see it on sensors either. You are ordered to investigate. Right as it seems you may be able to obtain visual confirmation, the lights snap off. ;7
-
Also, would that be possible not to remove the old, model-based syntax? The reason is pretty much the same as above (well, that, and it seems that BP added this syntax to every single glowpoint bank on every ship bigger than a bomber, making changing them back a bit of a chore :)).
Model-based syntax was never committed so I don't think there is any reason for maintaining it.
-
I did the BP glowpoints, and I am ok with moving everything to the new syntax.
-
http://youtu.be/-jWk3MxQJv4?hd=1
PROGRESS!!!
-
Any chance glowpoints can cast shadows? That video is all sorts of awesome, but at times it feels not as light, but as a paint of green invading (and leaving) the mesh.
-
1. The green wasn't the best color to demonstrate with.
2. Shadows are a possibility tho it might have too big of a performance impact.
3. Before anyone asks: Volumetric light cones will not be done. By me.
-
I was totally kidding about that one, Valathil!
-
I was totally kidding about that one, Valathil!
I'm never sure with you guys. Also sometimes im saying something will not be done and then do it anyway so to clarify no i wont do it not until we get unreal 4 voxel lighting. Take from that what you will.
-
Would such a lighting procedure be more efficient in a space game rather than in the usual FPS sets, theoretically speaking?
-
Equally so, I believe. In both cases, the computational effort is basically the same.
-
Color mix works only for pulse, right? Will there be way to make a cone light be color A down the normal and color B further from it?
-
Are there any lights anywhere in FS that behave that way? Because that would be an entirely new feature.
Not an impossible one, mind you, just a rather weird and mostly useless one (as in, it sounds like a lot of overhead in terms of coding time required vs a very limited number of use cases).
-
Are there any lights anywhere in FS that behave that way? Because that would be an entirely new feature.
Not an impossible one, mind you, just a rather weird and mostly useless one (as in, it sounds like a lot of overhead in terms of coding time required vs a very limited number of use cases).
There actually is... sorta. The laser tracers can transition from one color at birth to another color at death, over the course of its lifetime.
There *might* be usage of this feature for beams.
-
Umm, yes, but that's the laser bitmap's mipmap changing colour. That has nothing to do with the light emitted, and never has.
-
Umm, yes, but that's the laser bitmap's mipmap changing colour. That has nothing to do with the light emitted, and never has.
I distinctly remember at least one build where this was the case (light emitted by the laser's bolt was the same as the mipmap)... I think it was one of the .13 builds...
-
Ah, right, there's the @Laser Color and @Laser Color 2 thing that I completely forgot about. Still, I am not actually sure that there's really a good use case for the kind of thing Kobrar asked for.
-
It *might* be to simulate very intense spotlights, where it shifts from a white to the actual color... similar to how it is in the welcome beams:
:welcome:
-
It *might* be to simulate very intense spotlights, where it shifts from a white to the actual color... similar to how it is in the welcome beams:
Exactly what I had in mind. I thought of that looking at that awful green cone light in the preview.
-
Now I'm glad you (iirc) did all that work on custom options settings, because this really needs something more than launcher flags to configure properly. I'm pretty sure that my GTX 670 could handle shadowed glowpoint lights but not many other cards can do that at 60fps.
Very impressive work, by the way. This will make a huge difference in atmosphere.
-
Ok People listen up i got something special for you tonight.
I heard you cries. You wanted Shadows, you wanted Deferred Lighting with fancy Glowpoint lights.
NOW YOU CAN GET BOTH!
Introducing the SHADOWS&DEFERRED BETA 6 BUILD + PATCH: https://www.dropbox.com/s/5dg0z1z1or4vm18/Shadows%26Deferred_Beta_6.rar (https://www.dropbox.com/s/5dg0z1z1or4vm18/Shadows%26Deferred_Beta_6.rar)
Specifications for Glowpoint lights are here: https://docs.google.com/document/d/1Q736btTmHytE9FAPsV_QkZ_8WJk7vIbIt_zvGiiKYnA/edit (https://docs.google.com/document/d/1Q736btTmHytE9FAPsV_QkZ_8WJk7vIbIt_zvGiiKYnA/edit)
Have fun!
EDIT: There was a booboo in a logic check if you get crashes because of non textured glowpoints redownload the file
-
Well on the bright side, it doesn't involve exhaust artifacts.
(http://i97.photobucket.com/albums/l223/SpootKnight/FreeSpace/WarpGlitch.png)
It affects jumping ships on the bottom-half of the screen only; it looks as it should on the top-half.
I tried the first download and the edit just in case.
-
debug log please. also are you using SLI or CrossFire?
-
Sure thing. I'm running with Crossfire currently enabled so I'll give it a run with it disabled right now.
FreeSpace 2 Open version: 3.6.15
Passed cmdline options:
-spec_exp 11
-ogl_spec 60
-spec_static 0.8
-spec_point 0.6
-spec_tube 0.4
-ambient_factor 75
-missile_lighting
-soft_particles
-post_process
-fxaa
-fb_explosions
-cache_bitmaps
-ballistic_gauge
-dualscanlines
-orbradar
-rearm_timer
-targetinfo
-3dwarp
-ship_choice_3d
-weapon_choice_3d
-warp_flash
-snd_preload
-mod JAD Collector's Edition,mediavps_3612
Building file index...
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\JAD Collector's Edition\JAD_Collector's_Edition.vp' with a checksum of 0x9c4db224
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\JAD Collector's Edition\JAD_Collector's_Edition_Movies.vp' with a checksum of 0x9dd6e398
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Advanced.vp' with a checksum of 0x4b8b0f5a
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_AnimGlows.vp' with a checksum of 0x6a554026
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Assets.3612.vp' with a checksum of 0x59649c21
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Assets.vp' with a checksum of 0x529cc70f
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Effects.3612.vp' with a checksum of 0x9c510aa0
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Effects.vp' with a checksum of 0xb9a9a485
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Music.vp' with a checksum of 0xb3e21469
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_RadarIcons.vp' with a checksum of 0x31dd7781
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Root.3612.vp' with a checksum of 0x7c9d7e74
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Root.vp' with a checksum of 0x6ffd5c78
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\Root_fs2.vp' with a checksum of 0xce10d76c
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\smarty_fs2.vp' with a checksum of 0xddeb3b1e
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\sparky_fs2.vp' with a checksum of 0x164fe65a
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\sparky_hi_fs2.vp' with a checksum of 0xa11d56f1
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\stu_fs2.vp' with a checksum of 0xd77da83a
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\tango1_fs2.vp' with a checksum of 0x4c25221e
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\tango2_fs2.vp' with a checksum of 0x86920b82
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\tango3_fs2.vp' with a checksum of 0x705e8d71
Found root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\warble_fs2.vp' with a checksum of 0xd85c305d
Searching root 'C:\Program Files (x86)\GOG.com\Freespace 2\JAD Collector's Edition\' ... 5 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\JAD Collector's Edition\JAD_Collector's_Edition.vp' ... 72 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\JAD Collector's Edition\JAD_Collector's_Edition_Movies.vp' ... 7 files
Searching root 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\' ... 8 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Advanced.vp' ... 1283 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_AnimGlows.vp' ... 1641 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Assets.3612.vp' ... 315 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Assets.vp' ... 1527 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Effects.3612.vp' ... 10 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Effects.vp' ... 1876 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Music.vp' ... 32 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_RadarIcons.vp' ... 24 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Root.3612.vp' ... 13 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\mediavps_3612\MV_Root.vp' ... 94 files
Searching root 'C:\Program Files (x86)\GOG.com\Freespace 2\' ... 58 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\Root_fs2.vp' ... 157 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\smarty_fs2.vp' ... 10 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\sparky_fs2.vp' ... 3027 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\sparky_hi_fs2.vp' ... 1337 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\stu_fs2.vp' ... 2355 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\tango1_fs2.vp' ... 32 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\tango2_fs2.vp' ... 15 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\tango3_fs2.vp' ... 10 files
Searching root pack 'C:\Program Files (x86)\GOG.com\Freespace 2\warble_fs2.vp' ... 52 files
Found 24 roots and 13960 files.
Setting language to English
TBM => Starting parse of 'mv_core-lcl.tbm' ...
Initializing OpenAL...
OpenAL Vendor : Creative Labs Inc.
OpenAL Renderer : Software
OpenAL Version : 1.1
Found extension "ALC_EXT_EFX".
Sample rate: 44100 (44100)
EFX enabled: NO
Playback device: Generic Software on Speakers / Headphones (IDT High Definition Audio CODEC)
Capture device: Microphone Array (IDT High Defi
... OpenAL successfully initialized!
Failed to init speech
Initializing OpenGL graphics device at 1920x1200 with 32-bit color...
Initializing WGL...
Requested WGL Video values = R: 8, G: 8, B: 8, depth: 24, stencil: 8, double-buffer: 1
Actual WGL Video values = R: 8, G: 8, B: 8, depth: 24, stencil: 8, double-buffer: 1
OpenGL Vendor : ATI Technologies Inc.
OpenGL Renderer : ATI Mobility Radeon HD 5800 Series
OpenGL Version : 4.2.11931 Compatibility Profile Context
Using extension "GL_EXT_fog_coord".
Using extension "GL_ARB_multitexture".
Using extension "GL_ARB_texture_env_add".
Using extension "GL_ARB_texture_compression".
Using extension "GL_EXT_texture_compression_s3tc".
Using extension "GL_EXT_texture_filter_anisotropic".
Using extension "GL_ARB_texture_env_combine".
Using extension "GL_EXT_compiled_vertex_array".
Using extension "GL_EXT_draw_range_elements".
Using extension "GL_ARB_texture_mirrored_repeat".
Using extension "GL_ARB_texture_non_power_of_two".
Using extension "GL_ARB_vertex_buffer_object".
Using extension "GL_ARB_pixel_buffer_object".
Using extension "GL_SGIS_generate_mipmap".
Using extension "GL_EXT_framebuffer_object".
Using extension "GL_ARB_texture_rectangle".
Using extension "GL_EXT_bgra".
Using extension "GL_ARB_texture_cube_map".
Using extension "GL_EXT_texture_lod_bias".
Using extension "GL_ARB_point_sprite".
Using extension "GL_ARB_shading_language_100".
Using extension "GL_ARB_shader_objects".
Using extension "GL_ARB_vertex_shader".
Using extension "GL_ARB_fragment_shader".
Using extension "GL_ARB_shader_texture_lod".
Using extension "GL_ARB_texture_float".
Using extension "GL_ARB_draw_elements_base_vertex".
Using extension "GL_EXT_framebuffer_blit".
Using extension "GL_EXT_geometry_shader4".
Using extension "GL_EXT_texture_array".
Found special extension function "wglSwapIntervalEXT".
Compiling new shader:
Loading built-in default shader for: soft-v.sdr
Loading built-in default shader for: soft-f.sdr
Shader features:
Depth-blended Particles
Compiling new shader:
Loading built-in default shader for: soft-v.sdr
Loading built-in default shader for: soft-f.sdr
Shader features:
Distorted Particles
Compiling deferred light shader...
Loading built-in default shader for: deferred-v.sdr
Loading built-in default shader for: deferred-f.sdr
Compiling post-processing shader 1 ...
Loading built-in default shader for: post-v.sdr
Loading built-in default shader for: post-f.sdr
Compiling post-processing shader 2 ...
Loading built-in default shader for: post-v.sdr
Loading built-in default shader for: blur-f.sdr
Compiling post-processing shader 3 ...
Loading built-in default shader for: post-v.sdr
Loading built-in default shader for: blur-f.sdr
Compiling post-processing shader 4 ...
Loading built-in default shader for: post-v.sdr
Loading built-in default shader for: brightpass-f.sdr
Compiling post-processing shader 5 ...
Loading built-in default shader for: fxaa-v.sdr
Loading built-in default shader for: fxaa-f.sdr
Compiling post-processing shader 6 ...
Loading built-in default shader for: post-v.sdr
Loading built-in default shader for: fxaapre-f.sdr
Compiling post-processing shader 7 ...
Loading built-in default shader for: post-v.sdr
Loading built-in default shader for: ls-f.sdr
Compiling post-processing shader 8 ...
Loading built-in default shader for: shadowdebug-v.sdr
Loading built-in default shader for: shadowdebug-f.sdr
Max texture units: 8 (16)
Max elements vertices: 2147483647
Max elements indices: 16777215
Max texture size: 16384x16384
Max render buffer size: 16384x16384
Can use compressed textures: YES
Texture compression available: YES
Post-processing enabled: YES
Using trilinear texture filter.
OpenGL Shader Version: 4.20
... OpenGL init is complete!
Size of bitmap info = 742 KB
Size of bitmap extra info = 48 bytes
ANI cursorweb with size 24x24 (25.0% wasted)
GRAPHICS: Initializing default colors...
Game Settings Table: Using Standard Loops For SEXP Arguments
Game Settings Table: Using standard event chaining behavior
Game Settings Table: External shaders are DISABLED
SCRIPTING: Beginning initialization sequence...
SCRIPTING: Beginning Lua initialization...
LUA: Opening LUA state...
LUA: Initializing base Lua libraries...
LUA: Beginning ADE initialization
ADE: Initializing enumeration constants...
ADE: Assigning Lua session...
SCRIPTING: Beginning main hook parse sequence....
Wokka! Error opening file (scripting.tbl)!
TABLES: Unable to parse 'scripting.tbl'! Error code = 5.
TBM => Starting parse of 'mv_flak-sct.tbm' ...
TBM => Starting parse of 'mv_dbrs-sct.tbm' ...
TBM => Starting parse of 'mv_exp-sct.tbm' ...
SCRIPTING: Inititialization complete.
SCRIPTING: Splash screen overrides checked
SCRIPTING: Splash hook has been run
SCRIPTING: Splash screen conditional hook has been run
Using high memory settings...
Wokka! Error opening file (interface.tbl)!
WMCGUI: Unable to parse 'interface.tbl'! Error code = 5.
TBM => Starting parse of 'mv_effects-sdf.tbm' ...
Windows reported 16 joysticks, we found 0
Current soundtrack set to -1 in event_music_reset_choices
TBM => Starting parse of 'mv_music-mus.tbm' ...
TABLES => Unable to find 'colors.tbl'. Initialising colors with default values.
TBM => Starting parse of 'mv_effects-mfl.tbm' ...
Wokka! Error opening file (armor.tbl)!
TABLES: Unable to parse 'armor.tbl'! Error code = 5.
TBM => Starting parse of 'mv_effects-amr.tbm' ...
TBM => Starting parse of 'mv_effects-wxp.tbm' ...
BMPMAN: Found EFF (exp20.eff) with 75 frames at 20 fps.
BMPMAN: Found EFF (ExpMissileHit1.eff) with 92 frames at 20 fps.
BMPMAN: Found EFF (exp04.eff) with 49 frames at 22 fps.
BMPMAN: Found EFF (exp05.eff) with 93 frames at 20 fps.
BMPMAN: Found EFF (exp06.eff) with 92 frames at 22 fps.
BMPMAN: Found EFF (capflash.eff) with 40 frames at 10 fps.
BMPMAN: Found EFF (Maxim_Impact.eff) with 23 frames at 30 fps.
ANI Lamprey_Impact with size 80x80 (37.5% wasted)
TBM => Starting parse of 'mv_core-wep.tbm' ...
TBM => Starting parse of 'mv_effects-wep.tbm' ...
TBM => Starting parse of 'mv_assets-wep.tbm' ...
TBM => Starting parse of 'jadbeam_effects-wep.tbm' ...
TBM => Starting parse of 'mv_effects-obt.tbm' ...
TBM => Starting parse of 'mv_core-shp.tbm' ...
TBM => Starting parse of 'radar-shp.tbm' ...
TBM => Starting parse of 'mv_effects-shp.tbm' ...
TBM => Starting parse of 'mv_assets-shp.tbm' ...
TBM => Starting parse of 'jad4ever-shp.tbm' ...
TBM => Starting parse of 'jad3-shp.tbm' ...
TBM => Starting parse of 'hat-shp.tbm' ...
TBM => Starting parse of 'mv_core-hdg.tbm' ...
TBM => Starting parse of 'mv_root-hdg.tbm' ...
ANI support1 with size 108x24 (25.0% wasted)
ANI damage1 with size 148x25 (21.9% wasted)
ANI wingman1 with size 71x53 (17.2% wasted)
ANI wingman2 with size 35x53 (17.2% wasted)
ANI wingman3 with size 14x53 (17.2% wasted)
ANI toggle1 with size 57x20 (37.5% wasted)
ANI head1 with size 164x132 (48.4% wasted)
ANI weapons1 with size 126x20 (37.5% wasted)
ANI weapons1_b with size 150x20 (37.5% wasted)
ANI objective1 with size 149x21 (34.4% wasted)
ANI energy1 with size 12x41 (35.9% wasted)
ANI targetview1 with size 137x156 (39.1% wasted)
ANI targetview2 with size 4x96 (25.0% wasted)
ANI targetview3 with size 7x20 (37.5% wasted)
ANI 2_radar1 with size 209x170 (33.6% wasted)
ANI 2_energy2 with size 86x96 (25.0% wasted)
ANI 2_reticle1 with size 40x24 (25.0% wasted)
ANI targhit1 with size 31x21 (34.4% wasted)
ANI 2_leftarc with size 103x252 (1.6% wasted)
ANI 2_rightarc1 with size 103x252 (1.6% wasted)
ANI 2_toparc2 with size 35x24 (25.0% wasted)
ANI 2_toparc3 with size 41x29 (9.4% wasted)
ANI netlag1 with size 29x30 (6.3% wasted)
ANI 2_lead1 with size 26x26 (18.8% wasted)
ANI 2_lock1 with size 56x53 (17.2% wasted)
ANI 2_lockspin with size 100x100 (21.9% wasted)
ANI time1 with size 47x23 (28.1% wasted)
TBM => Starting parse of 'mv_effects-str.tbm' ...
loading animated cursor "cursor"
ANI cursor with size 24x24 (25.0% wasted)
TABLES => Starting parse of 'mainhall.tbl.
MediaVPs: Flaming debris script loaded!
MediaVPs: Explosions script loaded!
Ships.tbl is : VALID
Weapons.tbl is : VALID
cfile_init() took 2009
Compiling video-processing shader ...
Loading built-in default shader for: video-v.sdr
Loading built-in default shader for: video-f.sdr
Got event GS_EVENT_GAME_INIT (49) in state NOT A VALID STATE (0)
ANI cursor.ani with size 24x24 (25.0% wasted)
Got event GS_EVENT_MAIN_MENU (0) in state GS_STATE_INITIAL_PLAYER_SELECT (37)
Someone passed an extension to bm_load for file '42nd.pcx'
ANI 2_mainwalk.ani with size 209x477 (6.8% wasted)
ANI 2_mainflyby.ani with size 509x189 (26.2% wasted)
ANI 2_maincrane.ani with size 192x116 (9.4% wasted)
ANI 2_mainexit.ani with size 319x174 (32.0% wasted)
ANI 2_mainbarracks.ani with size 273x158 (38.3% wasted)
ANI 2_mainreadyroom.ani with size 231x145 (43.4% wasted)
ANI 2_maintechroom.ani with size 69x119 (7.0% wasted)
ANI 2_mainoptions.ani with size 337x206 (19.5% wasted)
ANI 2_maincampaign.ani with size 308x190 (25.8% wasted)
Got event GS_EVENT_NEW_CAMPAIGN (26) in state GS_STATE_MAIN_MENU (1)
Got event GS_EVENT_START_GAME (1) in state GS_STATE_MAIN_MENU (1)
=================== STARTING LEVEL LOAD ==================
ANI 2_Loading with size 824x43 (32.8% wasted)
ANI 2_Loading.ani with size 824x43 (32.8% wasted)
Starting model page in...
Beginning level bitmap paging...
BMPMAN: Found EFF (particleexp01.eff) with 10 frames at 8 fps.
BMPMAN: Found EFF (particlesmoke01.eff) with 54 frames at 15 fps.
BMPMAN: Found EFF (particlesmoke02.eff) with 39 frames at 24 fps.
TBM => Starting parse of 'mv_effects-fbl.tbm' ...
BMPMAN: Found EFF (WarpMap01.eff) with 30 frames at 30 fps.
BMPMAN: Found EFF (WarpMap02.eff) with 30 frames at 30 fps.
BMPMAN: Found EFF (Rock_Exp.eff) with 55 frames at 30 fps.
Loading warp model
Loading model 'warp.pof'
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Animated Effects
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Fog Effect
Animated Effects
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Loading built-in default shader for: main-g.sdr
Shader features:
Geometry Transformation
Shadow Mapping
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Deferred lighting
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Fog Effect
Deferred lighting
IBX: Found a good IBX to read for 'warp.pof'.
IBX-DEBUG => POF checksum: 0xbf802ad0, IBX checksum: 0xe7aa5a55 -- "warp.pof"
300
BMPMAN: Found EFF (shieldhit01a.eff) with 23 frames at 21 fps.
BMPMAN: Found EFF (shieldhit02a.eff) with 45 frames at 30 fps.
BMPMAN: Found EFF (shieldhit03a.eff) with 22 frames at 30 fps.
SHOCKWAVE => Loading default shockwave animation...
BMPMAN: Found EFF (shockwave01.eff) with 94 frames at 30 fps.
SHOCKWAVE => Default animation load: SUCCEEDED!!
MISSION LOAD: 'axm_jad2-65535.fs2'
Hmmm... Extension passed to mission_load...
Using alternate ship type name: NTSC Faustus
Starting mission message count : 205
Ending mission message count : 206
Current soundtrack set to -1 in event_music_reset_choices
Loading model 'fighter2t-04.pof'
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Diffuse Mapping
Glow Mapping
Specular Mapping
Normal Mapping
Environment Mapping
Animated Effects
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Fog Effect
Diffuse Mapping
Glow Mapping
Specular Mapping
Normal Mapping
Environment Mapping
Animated Effects
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Diffuse Mapping
Glow Mapping
Specular Mapping
Normal Mapping
Environment Mapping
Deferred lighting
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Fog Effect
Diffuse Mapping
Glow Mapping
Specular Mapping
Normal Mapping
Environment Mapping
Deferred lighting
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Diffuse Mapping
Specular Mapping
Environment Mapping
Animated Effects
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Fog Effect
Diffuse Mapping
Specular Mapping
Environment Mapping
Animated Effects
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Diffuse Mapping
Specular Mapping
Environment Mapping
Deferred lighting
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Fog Effect
Diffuse Mapping
Specular Mapping
Environment Mapping
Deferred lighting
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Diffuse Mapping
Glow Mapping
Specular Mapping
Environment Mapping
Animated Effects
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Fog Effect
Diffuse Mapping
Glow Mapping
Specular Mapping
Environment Mapping
Animated Effects
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Diffuse Mapping
Glow Mapping
Specular Mapping
Environment Mapping
Deferred lighting
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Fog Effect
Diffuse Mapping
Glow Mapping
Specular Mapping
Environment Mapping
Deferred lighting
IBX: Found a good IBX to read for 'fighter2t-04.pof'.
IBX-DEBUG => POF checksum: 0xe611ce17, IBX checksum: 0x97cf5fc2 -- "fighter2t-04.pof"
Loading model 'fighter2t-03.pof'
IBX: Found a good IBX to read for 'fighter2t-03.pof'.
IBX-DEBUG => POF checksum: 0x437b0cfb, IBX checksum: 0x7a6fa692 -- "fighter2t-03.pof"
Loading model 'science01.pof'
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Diffuse Mapping
Animated Effects
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Fog Effect
Diffuse Mapping
Animated Effects
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Diffuse Mapping
Deferred lighting
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Fog Effect
Diffuse Mapping
Deferred lighting
Unknown special object type $reactor while reading model science01.pof
IBX: Found a good IBX to read for 'science01.pof'.
IBX-DEBUG => POF checksum: 0xb5e70139, IBX checksum: 0x979d6181 -- "science01.pof"
Submodel 'science01d-solar1' is detail level 3 of 'science01a-solar1'
Submodel 'science01c-solar1' is detail level 2 of 'science01a-solar1'
Submodel 'science01b-solar1' is detail level 1 of 'science01a-solar1'
Submodel 'science01c-solar1-destroyed' is detail level 2 of 'science01a-solar1-destroyed'
Submodel 'science01b-solar1-destroyed' is detail level 1 of 'science01a-solar1-destroyed'
Loading model 'TerranSuper.pof'
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Diffuse Mapping
Specular Mapping
Normal Mapping
Environment Mapping
Animated Effects
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Fog Effect
Diffuse Mapping
Specular Mapping
Normal Mapping
Environment Mapping
Animated Effects
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Diffuse Mapping
Specular Mapping
Normal Mapping
Environment Mapping
Deferred lighting
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Fog Effect
Diffuse Mapping
Specular Mapping
Normal Mapping
Environment Mapping
Deferred lighting
Potential problem found: Unrecognized subsystem type 'fighterbay', believed to be in ship TerranSuper.pof
IBX: Found a good IBX to read for 'TerranSuper.pof'.
IBX-DEBUG => POF checksum: 0x7a19c79f, IBX checksum: 0x8d53e718 -- "TerranSuper.pof"
Submodel 'souperduperc' is detail level 2 of 'souperdupera'
Submodel 'souperduperd' is detail level 3 of 'souperdupera'
Submodel 'souperduperb' is detail level 1 of 'souperdupera'
Loading model 'capital02.pof'
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Diffuse Mapping
Glow Mapping
Animated Effects
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Fog Effect
Diffuse Mapping
Glow Mapping
Animated Effects
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Diffuse Mapping
Glow Mapping
Deferred lighting
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Fog Effect
Diffuse Mapping
Glow Mapping
Deferred lighting
Potential problem found: Unrecognized subsystem type 'reactor 4', believed to be in ship capital02.pof
Potential problem found: Unrecognized subsystem type 'reactor 5', believed to be in ship capital02.pof
Potential problem found: Unrecognized subsystem type 'reactor 3', believed to be in ship capital02.pof
Potential problem found: Unrecognized subsystem type 'reactor 2', believed to be in ship capital02.pof
Potential problem found: Unrecognized subsystem type 'reactor 1', believed to be in ship capital02.pof
Potential problem found: Unrecognized subsystem type 'fighterbay 1', believed to be in ship capital02.pof
Potential problem found: Unrecognized subsystem type 'fighterbay 2', believed to be in ship capital02.pof
Unknown special object type $baddaboom01-01 while reading model capital02.pof
Unknown special object type $baddaboom02-01 while reading model capital02.pof
IBX: Found a good IBX to read for 'capital02.pof'.
IBX-DEBUG => POF checksum: 0xd50a4925, IBX checksum: 0xb8859552 -- "capital02.pof"
Loading model 'capital01b.pof'
Potential problem found: Unrecognized subsystem type 'fighterbay', believed to be in ship capital01b.pof
IBX: Found a good IBX to read for 'capital01b.pof'.
IBX-DEBUG => POF checksum: 0x8c057b19, IBX checksum: 0x9b14174e -- "capital01b.pof"
Submodel 'turret01b' is detail level 1 of 'turret01a'
Submodel 'turret01c' is detail level 2 of 'turret01a'
Submodel 'turret02b' is detail level 1 of 'turret02a'
Submodel 'turret02c' is detail level 2 of 'turret02a'
Submodel 'turret03b' is detail level 1 of 'turret03a'
Submodel 'turret03c' is detail level 2 of 'turret03a'
Submodel 'turret04b' is detail level 1 of 'turret04a'
Submodel 'turret04c' is detail level 2 of 'turret04a'
Submodel 'turret05b' is detail level 1 of 'turret05a'
Submodel 'turret05c' is detail level 2 of 'turret05a'
Loading model 'corvette2r-01.pof'
Unknown special object type $path29 while reading model corvette2r-01.pof
IBX: Found a good IBX to read for 'corvette2r-01.pof'.
IBX-DEBUG => POF checksum: 0x7420b86f, IBX checksum: 0x4dc3a564 -- "corvette2r-01.pof"
Submodel 'turret21b' is detail level 1 of 'turret21a'
Submodel 'turret22b' is detail level 1 of 'turret22a'
Loading model 'fighter13.pof'
IBX: Found a good IBX to read for 'fighter13.pof'.
IBX-DEBUG => POF checksum: 0x1ded4cfa, IBX checksum: 0x49a4ec4c -- "fighter13.pof"
Loading model 'fighter06.pof'
IBX: Found a good IBX to read for 'fighter06.pof'.
IBX-DEBUG => POF checksum: 0xc5eced1d, IBX checksum: 0x713dda25 -- "fighter06.pof"
Allocating space for at least 5 new ship subsystems ... a total of 200 is now available (5 in-use).
OpenGL: Created 512x512 FBO!
Loading model 'starfield.pof'
Model starfield.pof has a null moment of inertia! (This is only a problem if the model is a ship.)
IBX: Found a good IBX to read for 'starfield.pof'.
IBX-DEBUG => POF checksum: 0x51900597, IBX checksum: 0xd179f0ac -- "starfield.pof"
ANI debris01 with size 51x38 (40.6% wasted)
ANI debris02 with size 26x19 (40.6% wasted)
ANI debris04 with size 36x27 (15.6% wasted)
=================== STARTING LEVEL DATA LOAD ==================
Loading model 'support2t-01.pof'
IBX: Found a good IBX to read for 'support2t-01.pof'.
IBX-DEBUG => POF checksum: 0x6512c7b6, IBX checksum: 0xc0ade8e6 -- "support2t-01.pof"
Submodel 'bodyb' is detail level 1 of 'bodya'
Submodel 'bodyc' is detail level 2 of 'bodya'
Submodel 'bodyd' is detail level 3 of 'bodya'
Loading model 'support2v-01.pof'
IBX: Found a good IBX to read for 'support2v-01.pof'.
IBX-DEBUG => POF checksum: 0xbca18023, IBX checksum: 0x16765db6 -- "support2v-01.pof"
Submodel 'hercb' is detail level 1 of 'herca'
Submodel 'hercc' is detail level 2 of 'herca'
Submodel 'hercd' is detail level 3 of 'herca'
Allocating space for at least 229 new ship subsystems ... a total of 400 is now available (15 in-use).
About to page in ships!
ANI shield-f06 with size 112x93 (27.3% wasted)
ANI shieldft-04 with size 112x93 (27.3% wasted)
ANI shield-f13 with size 112x93 (27.3% wasted)
ANI shieldft-03 with size 112x93 (27.3% wasted)
BMPMAN: Found EFF (Subach_AniBitmap.eff) with 6 frames at 5 fps.
BMPMAN: Found EFF (PrometheusR_AniBitmap.eff) with 12 frames at 5 fps.
BMPMAN: Found EFF (Prometheus_AniBitmap.eff) with 12 frames at 5 fps.
BMPMAN: Found EFF (Kayser_AniBitmap.eff) with 4 frames at 5 fps.
ANI Kayser_Particle with size 80x80 (37.5% wasted)
ANI Lamprey_Particle with size 92x86 (32.8% wasted)
BMPMAN: Found EFF (particle_red.eff) with 11 frames at 22 fps.
BMPMAN: Found EFF (SbeamAglow.eff) with 24 frames at 60 fps.
BMPMAN: Found EFF (SbeamAC.eff) with 30 frames at 40 fps.
BMPMAN: Found EFF (particle_blue.eff) with 11 frames at 22 fps.
BMPMAN: Found EFF (AAAbeamAglow.eff) with 35 frames at 30 fps.
BMPMAN: Found EFF (AAAbeamAB.eff) with 15 frames at 15 fps.
BMPMAN: Found EFF (particle_green.eff) with 11 frames at 22 fps.
BMPMAN: Found EFF (GreenBeamGlow.eff) with 30 frames at 60 fps.
BMPMAN: Found EFF (GreenBeam2Glow.eff) with 30 frames at 60 fps.
Loading model 'Blip.pof'
IBX: Found a good IBX to read for 'Blip.pof'.
IBX-DEBUG => POF checksum: 0x8701ba27, IBX checksum: 0x3ee2fcac -- "Blip.pof"
Submodel 'blipb' is detail level 1 of 'blipa'
Submodel 'blipc' is detail level 2 of 'blipa'
Submodel 'blipd' is detail level 3 of 'blipa'
Loading model 'rockeye.pof'
IBX: Found a good IBX to read for 'rockeye.pof'.
IBX-DEBUG => POF checksum: 0x821bc51b, IBX checksum: 0x5a0fae49 -- "rockeye.pof"
Submodel 'rockeye-b' is detail level 1 of 'rockeye-a'
Submodel 'rockeye-c' is detail level 2 of 'rockeye-a'
Submodel 'thruster01b' is detail level 1 of 'thruster01a'
Submodel 'thruster01c' is detail level 2 of 'thruster01a'
Loading model 'Tempest.pof'
IBX: Found a good IBX to read for 'Tempest.pof'.
IBX-DEBUG => POF checksum: 0x4fcb12af, IBX checksum: 0xef8699b5 -- "Tempest.pof"
Loading model 'NewHornet.pof'
IBX: Found a good IBX to read for 'NewHornet.pof'.
IBX-DEBUG => POF checksum: 0x2c76000e, IBX checksum: 0x19f7f55e -- "NewHornet.pof"
Loading model 'bombardier.pof'
IBX: Found a good IBX to read for 'bombardier.pof'.
IBX-DEBUG => POF checksum: 0x11edee12, IBX checksum: 0x19816d20 -- "bombardier.pof"
Submodel 'realhornet-b' is detail level 1 of 'realhornet-a'
Submodel 'realhornet-c' is detail level 2 of 'realhornet-a'
Loading model 'crossbow.pof'
No subsystems found for model "crossbow.pof".
IBX: Found a good IBX to read for 'crossbow.pof'.
IBX-DEBUG => POF checksum: 0x19e682bb, IBX checksum: 0x885d0786 -- "crossbow.pof"
Loading model 'piranha.pof'
IBX: Found a good IBX to read for 'piranha.pof'.
IBX-DEBUG => POF checksum: 0x484195d2, IBX checksum: 0xf272dc8a -- "piranha.pof"
Loading model 'stilettoII.pof'
IBX: Found a good IBX to read for 'stilettoII.pof'.
IBX-DEBUG => POF checksum: 0xc03ac47f, IBX checksum: 0x21dd34b9 -- "stilettoII.pof"
Loading model 'infyrno.pof'
IBX: Found a good IBX to read for 'infyrno.pof'.
IBX-DEBUG => POF checksum: 0xdd26cdd3, IBX checksum: 0xf1867e03 -- "infyrno.pof"
Submodel 'realhornet-b' is detail level 1 of 'realhornet-a'
Submodel 'realhornet-c' is detail level 2 of 'realhornet-a'
Loading model 'cmeasure01.pof'
IBX: Found a good IBX to read for 'cmeasure01.pof'.
IBX-DEBUG => POF checksum: 0x562739c3, IBX checksum: 0x76256515 -- "cmeasure01.pof"
Loading model 'MX-50.pof'
DDS ERROR: Couldn't open 'wep-mx50-shine.dds' -- DDS was in an unsupported/unknown format
IBX: Found a good IBX to read for 'MX-50.pof'.
IBX-DEBUG => POF checksum: 0x25d2520e, IBX checksum: 0xc624dc0f -- "MX-50.pof"
Loading model 'ShivanCluster.pof'
BMPMAN: Found EFF (smissile1-glow.eff) with 20 frames at 20 fps.
IBX: Found a good IBX to read for 'ShivanCluster.pof'.
IBX-DEBUG => POF checksum: 0x4b5c01e9, IBX checksum: 0x8369b9d8 -- "ShivanCluster.pof"
Loading model 'S_Rockeye.pof'
IBX: Found a good IBX to read for 'S_Rockeye.pof'.
IBX-DEBUG => POF checksum: 0x4a2c27f4, IBX checksum: 0x2098b367 -- "S_Rockeye.pof"
Loading model 'hornet.pof'
IBX: Found a good IBX to read for 'hornet.pof'.
IBX-DEBUG => POF checksum: 0x066a989a, IBX checksum: 0x8d7227a4 -- "hornet.pof"
Loading model 'S_Harpoon.pof'
IBX: Found a good IBX to read for 'S_Harpoon.pof'.
IBX-DEBUG => POF checksum: 0x76d846b5, IBX checksum: 0xf7e6e8a2 -- "S_Harpoon.pof"
Loading model 'debris01.pof'
IBX: Found a good IBX to read for 'debris01.pof'.
IBX-DEBUG => POF checksum: 0x974f214b, IBX checksum: 0x0cb49c79 -- "debris01.pof"
Loading model 'debris02.pof'
IBX: Found a good IBX to read for 'debris02.pof'.
IBX-DEBUG => POF checksum: 0x8e0eed50, IBX checksum: 0x3e979514 -- "debris02.pof"
BMPMAN: Found EFF (explode1.eff) with 43 frames at 25 fps.
BMPMAN: Found EFF (PWmuzzle.eff) with 4 frames at 30 fps.
BMPMAN: Found EFF (Gmuzzle.eff) with 5 frames at 30 fps.
BMPMAN: Found EFF (Bmuzzle.eff) with 5 frames at 30 fps.
BMPMAN: Found EFF (Cmuzzle.eff) with 4 frames at 30 fps.
Paging in mission messages
Stopping model page in...
ANI Lamprey_Impact.ani with size 80x80 (37.5% wasted)
ANI support1.ani with size 108x24 (25.0% wasted)
ANI damage1.ani with size 148x25 (21.9% wasted)
ANI wingman1.ani with size 71x53 (17.2% wasted)
ANI wingman2.ani with size 35x53 (17.2% wasted)
ANI wingman3.ani with size 14x53 (17.2% wasted)
ANI toggle1.ani with size 57x20 (37.5% wasted)
ANI head1.ani with size 164x132 (48.4% wasted)
ANI weapons1.ani with size 126x20 (37.5% wasted)
ANI weapons1_b.ani with size 150x20 (37.5% wasted)
ANI objective1.ani with size 149x21 (34.4% wasted)
ANI energy1.ani with size 12x41 (35.9% wasted)
ANI targetview1.ani with size 137x156 (39.1% wasted)
ANI targetview2.ani with size 4x96 (25.0% wasted)
ANI targetview3.ani with size 7x20 (37.5% wasted)
ANI 2_radar1.ani with size 209x170 (33.6% wasted)
ANI 2_energy2.ani with size 86x96 (25.0% wasted)
ANI 2_reticle1.ani with size 40x24 (25.0% wasted)
ANI targhit1.ani with size 31x21 (34.4% wasted)
ANI 2_leftarc.ani with size 103x252 (1.6% wasted)
ANI 2_rightarc1.ani with size 103x252 (1.6% wasted)
ANI 2_toparc2.ani with size 35x24 (25.0% wasted)
ANI 2_toparc3.ani with size 41x29 (9.4% wasted)
ANI netlag1.ani with size 29x30 (6.3% wasted)
ANI 2_lead1.ani with size 26x26 (18.8% wasted)
ANI 2_lock1.ani with size 56x53 (17.2% wasted)
ANI 2_lockspin.ani with size 100x100 (21.9% wasted)
ANI time1.ani with size 47x23 (28.1% wasted)
ANI 2_Loading.ani with size 824x43 (32.8% wasted)
ANI debris01.ani with size 51x38 (40.6% wasted)
ANI debris02.ani with size 26x19 (40.6% wasted)
ANI debris04.ani with size 36x27 (15.6% wasted)
ANI shield-f06.ani with size 112x93 (27.3% wasted)
ANI shieldft-04.ani with size 112x93 (27.3% wasted)
ANI shield-f13.ani with size 112x93 (27.3% wasted)
ANI shieldft-03.ani with size 112x93 (27.3% wasted)
ANI Kayser_Particle.ani with size 80x80 (37.5% wasted)
ANI Lamprey_Particle.ani with size 92x86 (32.8% wasted)
User bitmap 'TMP512x512+8'
User bitmap 'TMP512x512+8'
User bitmap 'TMP256x256+8'
Bmpman: 1947/4750 bitmap slots in use.
Ending level bitmap paging...
=================== ENDING LOAD ================
Real count = 572, Estimated count = 425
================================================
MediaVPs: Flaming debris script ACTIVE!
SCRIPTING: Starting flashy deaths script loading
Received post for event GS_EVENT_START_BRIEFING during state transtition. Find Allender if you are unsure if this is bad.
Got event GS_EVENT_START_BRIEFING (15) in state GS_STATE_START_GAME (52)
ANI 2_BriefMap with size 918x400 (21.9% wasted)
ANI iconwing01 with size 32x28 (12.5% wasted)
Loading model 'fighter2t-02.pof'
IBX: Found a good IBX to read for 'fighter2t-02.pof'.
IBX-DEBUG => POF checksum: 0xb236e2c1, IBX checksum: 0x153c31b5 -- "fighter2t-02.pof"
Loading model 'fighter2t-05.pof'
IBX: Found a good IBX to read for 'fighter2t-05.pof'.
IBX-DEBUG => POF checksum: 0xbfb37609, IBX checksum: 0x207ec69a -- "fighter2t-05.pof"
Loading model 'PersyHat.pof'
Model PersyHat.pof has a null moment of inertia! (This is only a problem if the model is a ship.)
IBX: Found a good IBX to read for 'PersyHat.pof'.
IBX-DEBUG => POF checksum: 0x78784001, IBX checksum: 0x2c31f8c0 -- "PersyHat.pof"
ANI iconSD4 with size 56x24 (25.0% wasted)
ANI iconScalpel with size 56x24 (25.0% wasted)
ANI iconflail with size 56x24 (25.0% wasted)
ANI iconPromS with size 56x24 (25.0% wasted)
ANI iconNewton with size 56x24 (25.0% wasted)
ANI iconKayser with size 56x24 (25.0% wasted)
ANI iconCirce with size 56x24 (25.0% wasted)
ANI iconLich with size 56x24 (25.0% wasted)
Loading model 'tempest_tech.pof'
IBX: Found a good IBX to read for 'tempest_tech.pof'.
IBX-DEBUG => POF checksum: 0x457ab425, IBX checksum: 0xc444d920 -- "tempest_tech.pof"
Loading model 'newhornet_tech.pof'
IBX: Found a good IBX to read for 'newhornet_tech.pof'.
IBX-DEBUG => POF checksum: 0xe97f1fa7, IBX checksum: 0xb0958a83 -- "newhornet_tech.pof"
Loading model 'crossbow_tech.pof'
IBX: Found a good IBX to read for 'crossbow_tech.pof'.
IBX-DEBUG => POF checksum: 0x3c2d3c20, IBX checksum: 0xe793cd75 -- "crossbow_tech.pof"
Loading model 'piranha_tech.pof'
IBX: Found a good IBX to read for 'piranha_tech.pof'.
IBX-DEBUG => POF checksum: 0x4334dee5, IBX checksum: 0x19e212e4 -- "piranha_tech.pof"
Loading model 'stilettoII_tech.pof'
IBX: Found a good IBX to read for 'stilettoII_tech.pof'.
IBX-DEBUG => POF checksum: 0xf50214c4, IBX checksum: 0xc31b26fb -- "stilettoII_tech.pof"
ANI iconT-fighter with size 24x29 (9.4% wasted)
ANI FadeiconT-fighter with size 24x29 (9.4% wasted)
ANI FadeiconT-fighter.ani with size 24x29 (9.4% wasted)
ANI iconplanet with size 183x182 (28.9% wasted)
ANI FadeiconPlanet with size 183x182 (28.9% wasted)
ANI FadeiconPlanet.ani with size 183x182 (28.9% wasted)
ANI iconT-vette with size 80x31 (3.1% wasted)
ANI fadeiconT-vette with size 80x31 (3.1% wasted)
ANI fadeiconT-vette.ani with size 80x31 (3.1% wasted)
ANI icont-cruiser with size 70x18 (43.8% wasted)
ANI FadeiconT-cruiser with size 70x18 (43.8% wasted)
ANI FadeiconT-cruiser.ani with size 70x18 (43.8% wasted)
Frame 0 too long!!: frametime = 23.582 (23.582)
ANI iconT-fighter.ani with size 24x29 (9.4% wasted)
Got event GS_EVENT_ENTER_GAME (2) in state GS_STATE_BRIEFING (10)
Entering game at time = 30.475
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Diffuse Mapping
message 'Paranooooid' with invalid head. Fix by assigning persona to the message.
ANI Head-CM2b.ani with size 160x120 (6.3% wasted)
message 'Braaaaaains...' with invalid head. Fix by assigning persona to the message.
ANI Head-VP1a.ani with size 160x120 (6.3% wasted)
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Diffuse Mapping
Glow Mapping
Specular Mapping
Environment Mapping
Deferred lighting
Shadows
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Diffuse Mapping
Glow Mapping
Specular Mapping
Normal Mapping
Environment Mapping
Deferred lighting
Shadows
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Diffuse Mapping
Specular Mapping
Environment Mapping
Deferred lighting
Shadows
message 'PSHAW' with invalid head. Fix by assigning persona to the message.
ANI Head-CM2a.ani with size 160x120 (6.3% wasted)
1781 frames executed in 30.013 seconds, 59.341 frames per second.
message 'Oh hey, NTF!' with invalid head. Fix by assigning persona to the message.
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Lighting
Diffuse Mapping
Shadows
Compiling new shader:
Loading built-in default shader for: main-v.sdr
Loading built-in default shader for: main-f.sdr
Shader features:
Diffuse Mapping
Glow Mapping
ANI Head-TP7b.ani with size 160x120 (6.3% wasted)
Got event GS_EVENT_END_GAME (4) in state GS_STATE_GAME_PLAY (2)
SOUND: g:\fsopen_deferred\code\sound\ds.cpp:1268 - OpenAL error = 'Invalid Operation'
Unloading in mission messages
Got event GS_EVENT_QUIT_GAME (5) in state GS_STATE_MAIN_MENU (1)
Freeing all existing models...
... Log closed, Sat Nov 17 14:40:35 2012
Edit:
No dice on Crossfire being disabled.
-
could you try disabling shadows with -shadow_quality 0 and see if its a unintended side effect of the merge. Then please try an older deferred build and see if it has to do with new drivers or something
-
All right, it didn't happen when I added the -shadow_quality flag. Still want me to check the other deferred lighting build?
-
nope
-
Could you elaborate on pulse options? Especially "bias" and "exponent".
-
done
-
Thanks.
Also, I've noticed that it's impossible to tie a glowpoint to a non-physical subsystem. This would be a very useful feature, for instance, you could make thruster lights that go out when the associated thruster is destroyer (this could benefit from a system taking throttle into account as well, but let's leave that for later), lights on radar dishes that go out when the sensor subsystem is destroyed and fighterbay lighting that goes down when the fighterbay gets torpedoed. Or simply a headlight that can be broken by either a collision or an unlucky shot. Do you think you could code something like that in?
-
It affects jumping ships on the bottom-half of the screen only; it looks as it should on the top-half.
I tried the first download and the edit just in case.
We've found and fixed this issue.
If you ever meet a person working on AMD's OpenGL drivers, hit them over the head with a table for us, please.
-
We've found and fixed this issue.
If you ever meet a person working on AMD's OpenGL drivers, hit them over the head with a table for us, please.
You got it. :yes:
-
When I read these kind of posts I just remember that time when I was about to buy an AMD card and decided to spend a few more bucks to get an Nvidia counterpart.
So glad I did that, not sure if I would have had these problems but hell, I don't want to discover it.
-
Wow, this adds a lot more than you'd expect to the game when used/abused correctly.
Table updates for this absolutely have to go into the next FSU release.
-
I spotted this bug: http://postimage.org/image/64cjebrl7/full/
-
Can Reproduce. Only caveat I can reproduce in Trunk as well
-
EDIT: Oh, you reproduced it. :)
In that case, the only other thing I've noticed is severe framerate stutter when bombs explode. This is on an old 280gtx until I get my new one, just FYI.
-
have you enabled framebuffer explosions? also i have 260 and i have no problems.
Also i traced the black thing to a nullvec normal on the charybdis model. this model well be replaced next mediavp anyway
-
Tried both with and without, without framebuffer shockwaves it seems to be just a tiny, tiny bit better but I'm not sure.
-
try trunk
-
Moved to the new graphics card yesterday, problem's gone now for some reason.
-
Do glowpoint lights cast shadows on their own parent? I've started playing around with them, and they don't seem to.
-
No, glowpoint lights do not cast shadows.
-
At all, or only on the parent ship? Either way, while this has potential benefits, it can also look pretty strange. Also, is it going to stay this way?
-
I thought I gave a pretty straight answer.
No, glowpoint lights NEVER cast shadows on anything.
No, it is not a good idea to enable that function, because performance would go down really fast.
Yes, it is very probably going to stay that way, unless someone discovers a way to not waste tons of render cycles on additional shadow map passes.
-
The way for them not to appear strange is to make them small so that lack of shadows becomes irrelevant. Designed that way, they are amazing. My 2 cents.
-
Getting a crash on the first mission of the new ASW Act 2 mod with the Deferred lighting + Shadows build. Happens a little while after the first wings jump in. The Shadows 3.1 build doesn't seem to suffer from this problem. I redownloaded the file because a crash was mentioned as being fixed, then I ran both the release and the debug and it does the same; freeze with an appcrash dialog in the background when I alt tab. I get some errors when starting the mission, though:
For asteroid 'Large Asteroid', detail level
mismatch (POF needs 3)
KERNELBASE.dll! WaitForSingleObjectEx + 152 bytes
kernel32.dll! WaitForSingleObjectEx + 67 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
kernel32.dll! BaseThreadInitThunk + 18 bytes
ntdll.dll! RtlInitializeExceptionChain + 99 bytes
ntdll.dll! RtlInitializeExceptionChain + 54 bytes
The problem doesn't seem to exist in the nightly build from November 21st.
-
I've encountered this too, using a BP build (basically this + antipodes). FSF told me to make sure it works on the official release (as we didn't had much time), but I can confirm that it happens.
-
Speaking of BP, I tried about half of the Blue Planet 2 missions, and I didn't encounter the bug, so it seems like an occasional thing, so it seem a bit "rare". But when it happens, it will happen every time.
-
Getting a crash on the first mission of the new ASW Act 2 mod with the Deferred lighting + Shadows build. Happens a little while after the first wings jump in. The Shadows 3.1 build doesn't seem to suffer from this problem. I redownloaded the file because a crash was mentioned as being fixed, then I ran both the release and the debug and it does the same; freeze with an appcrash dialog in the background when I alt tab. I get some errors when starting the mission, though:
For asteroid 'Large Asteroid', detail level
mismatch (POF needs 3)
KERNELBASE.dll! WaitForSingleObjectEx + 152 bytes
kernel32.dll! WaitForSingleObjectEx + 67 bytes
kernel32.dll! WaitForSingleObject + 18 bytes
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
fs2_open_3_6_15d_Shadows&Deferred_Beta_6_INF_SSE2.exe! <no symbol>
kernel32.dll! BaseThreadInitThunk + 18 bytes
ntdll.dll! RtlInitializeExceptionChain + 99 bytes
ntdll.dll! RtlInitializeExceptionChain + 54 bytes
The problem doesn't seem to exist in the nightly build from November 21st.
Just to be clear, this error has nothing to do with the deferred render code.
-
But it might the shadow map renderering. I have to look at it when i have the time.
-
Well on the bright side, it doesn't involve exhaust artifacts.
(http://i97.photobucket.com/albums/l223/SpootKnight/FreeSpace/WarpGlitch.png)
It affects jumping ships on the bottom-half of the screen only; it looks as it should on the top-half.
I tried the first download and the edit just in case.
Just to say that I'm experiencing the exact same bug with the latest build.
I have (obviously) an AMD card (radeon 6850) with the latest catalyst drivers (12.10).
Need me to post a debug log?
Also, how can I enable godrays in this build? I seem to not find the required tables to turn them on (all attachments were deleted in other threads).
-
Lightshafts should be on by default (and IIRC, they're already in trunk), check the launcher if the flag to disable them isn't on.
-
Lightshafts should be on by default (and IIRC, they're already in trunk), check the launcher if the flag to disable them isn't on.
It isn't.
(note, I am using beta6 build with mediavps 3612 and some extra mods (sobek, etc.), the wxlauncher has the option to disable lightshafts and it's off as it should be, enable post-processing is on, etc)
e2: my command line:
C:\Media\FS\Game\Freespace 2\fs2_open_3_6_15r_Shadows&Deferred_Beta_6_INF_SSE2.exe -mod
SobekMod-Ultra,SathMod-4096,Arcadia,mediavps_3612,Rak-Ultra -missile_lighting -3dshockwave -post_process
-soft_particles -fxaa -snd_preload -fb_explosions -window -shadow_quality 2
plus the custom flag: -shadow_quality 2
-
Do you have a lightshaft entry in you post processing table?
-
No I haven't, that's what I was trying to find. The only post-processing table file I can find is inside MV_Root.vp in mediavps folder with the old culprits, contrast, distort noise, film grain, saturation, stripes). I tried to find a new tbl that had lightshaft entries in the old godrays thread but it's been eaten by grues or something.
I'll try to find it in the wiki. Is it there?
-
I'll try to find it in the wiki. Is it there?
http://www.hard-light.net/wiki/index.php/Post_processing.tbl#.23Light_Shafts (http://www.hard-light.net/wiki/index.php/Post_processing.tbl#.23Light_Shafts)
-
Yeah, I found it myself. Was building my own post_processing.tbl right now... but I noticed that "FSO executables" already use the default tbl including the lightshafts... odd. Still not working. The shaders are not required, right? The beta 6 already includes them?
Wait. Perhaps the Mediavps are overriding the tables.
Nope. Disabling mediavps does nothing.
-
Need me to post a debug log?
In case something doesn't work, yeah, debug log seems obligatory.
-
Need me to post a debug log?
In case something doesn't work, yeah, debug log seems obligatory.
[attachment deleted by a basterd]
-
I figured it'd be best to start here with this. In the new BP build, nameplates seem to have a Photoshop-like priority to them. Where an explosion, laser, beam, etc effect would be in front of the texture, the nameplate itself would be seen floating as if it were in front. Is this a result of deferred lighting/shadows coding or is the cause somewhere else?
-
Run Trunk see if it happens there and i think you can figure out "Yes or No" for yourself.
-
Any developments on this and/or the shadows build? Just curious.
-
Nemesis6: This actually is the shadows build, in that it has been rolled into the Deferred Lighting.
-
Any developments on this and/or the shadows build? Just curious.
Using them for the BP release seems to suggest that a significant fraction of users will be unable to handle the deferred lighting code unless it's a launcher toggle option somehow.
-
It won't work properly on OS X until someone modifies the FSO OS X OpenGL code to work with OpenGL 3 (discussed here (http://www.hard-light.net/forums/index.php?topic=83509.msg1669369#msg1669369)).
From what The E's said (http://www.hard-light.net/forums/index.php?topic=83291.msg1665671#msg1665671), anyone who can't run deferred lighting (which should eventually just be anyone who doesn't have an OpenGL 3+ graphics card and anyone running OS X 10.6 or earlier) will have to use the fixed function rendering pipeline (aka no shaders/-no_glsl).
-
The deferred lighting and shadows does not require opengl 3 it runs on 2 I coded it that way especially because osx doesnt work. There might be 1 or 2 required extensions tho that might cause problems if they are missing.
-
It's amazing how quickly Apple and other development communities are nixing Snow Leopard support, and it looks like without those extensions and SDK support, we're going to have a hard time supporting it much longer as well.
-
It's amazing how quickly Apple and other development communities are nixing Snow Leopard support, and it looks like without those extensions and SDK support, we're going to have a hard time supporting it much longer as well.
And snow leopards are already endangered as it is... (http://en.wikipedia.org/wiki/Snow_leopard#Conservation_status) :(
/me is typing this on a MacBook Pro running SL.
Hard to believe SCP has been making Tiger and Leopard builds for so long.
The deferred lighting and shadows does not require opengl 3 it runs on 2 I coded it that way especially because osx doesnt work. There might be 1 or 2 required extensions tho that might cause problems if they are missing.
It wouldn't surprise me at all if those extensions were missing from at least one version of OS X. :sigh: Is there any reasonable way to find out what they were (i.e., without doing a ton of work)?
Also, if Snow Leopard support is (slowly) on its way out, and since all later versions of OS X support OpenGL 3.2 Core profile, maybe the main rendering pipeline, along with deferred lighting and shadows, should (eventually) become OpenGL 3 anyway? Not that I really know that much about OpenGL... :nervous:
-
It would be lovely if someone could compile a 3.6.18 build with both shadows and deferred lighting. There is the 3.6.17 BP build, but it has quite a few quirks.
-
Might I interest you in some updated builds, sir? (http://www.hard-light.net/forums/index.php?topic=83318.0)
-
How high does the -shadow_quality setting go? I looked through the thread but only the lower settings are discussed.
Edit: Nevermind, found it. The answer is 2. :)
-
Just a small suggestion: i found that having shadows in small ships like fighters is almost useless...
Having the possibility to choose what object you wanna affect would be great since it should have less performance impact and allows people to find shadows on ships where are really noticeable like capships and stations (and player ship obviously).
Just my 2 cents :)
-
Just a small suggestion: i found that having shadows in small ships like fighters is almost useless...
Lies. I actually found those were the most noticeable, especially when you're flying in formation in a wing.
One thing that would be good is to disable shadow on ships/objects that are very far away. For example I noticed a massive slowdown in missions with needlessly large asteroid fields.
-
Obviously you need a better sound card. :P
-
The distances at which shadows are rendered are currently fixed. FSO uses a cascading shadow map render with three shadow maps, with distances of 400, 3000 and 20000 as cutoff points (As in, everything up to 400 units away from the camera gets rendered into the first map, everything up to 3000 in the second and so on).
What we do not want to do is introduce lots of special cases here. I think what would be worthwhile is to introduce commandline switches or mission spec fields to control the shadow cascades.
And yes, shadows on the player ship or cast by the player ship are the most noticeable ones, so they're not gonna go away.
-
One thing that would be good is to disable shadow on ships/objects that are very far away. For example I noticed a massive slowdown in missions with needlessly large asteroid fields.
I don't know much about performance, but asteroids lod 2/3 have like 80 faces or less. With 256 asteroid cap, that's about 20k or less faces total and each asteroid takes only a handful pixels on the shadowmap 3. Should they impact the performance this much?
-
I don't think it's about how much pixel they take on the map, it's about calculating those pixels in the first place.
-
Faces/vertices don't matter unless the engine uses shadow volumes (which I don't think it does). The number of screen pixels a single shadow takes should have no bearing on performance for either shadow maps or shadow volumes.
I'm actually sort of curious about the method of how shadows in FSO work, because my understanding of how shadow mapping is often implemented is that performance is independent of scene complexity. It should only depend on shadow texture size.
-
so ... ahh.... what's the current gameplan regarding placing this into the main trunk? :nervous:
Is this going into 3.7.2 or are you gonna be wild crazy and call it 3.8? ;7
It almost deserves it.
-
Regarding the implementation details: FSO uses a technique called cascading shadow maps. This uses several, in our case three, shadow maps to make sure that texel density is highest the closer to the camera an object appears.
While shadow mapping is orders of magnitude faster than regular rendering, it's still a process with a runtime that increases with object count.
It should also be noted that the FSO render pipeline as currently implemented isn't very efficient when it comes to batching render calls, especially in a situation like this one, meaning that there's a few tricks here that we're missing right now.
-
Is this making its way into Trunk with 3.7.0 Final out now?
-
Not sure. I bet it makes its way beyond 3.7.0