[S-99]

That shivan beam looks a lot nicer than what it was in the beginning of this thread. That one is cool. But still, for beams, give them a little more distinction than just color differentiation. Like the shivan beams should look really super refined, and the terran and vasudan beams no where near as refined because it's still a new technology for the gtva. That's what was like so cool about the beams in the current vp set. Terran beams in the current vp set looked really unrefined like they were in the stone age compared to advanced shivan beams.

[neoterran]

Hey I'm using your modified beams and I like them, but keep on improving them ! I'll use version 1.1, 1.2, 1.3 alpha 4

One thing that I saw tho - A deimos cruiser using a red beam... that didn't strike me as being correct.

The shivan main beams look really good with this effect.

[Herra Tohtori]

Okay, thanks for feedback.


It looks to me as if some beams just *want* to use the texture called beam-white2.*


I have no ide why this is, but at least BFRed does this. I tested the beams practically only in Surrender, Belisarius! and High Noon, so I've not seen all of the beams.

As I told earlier, the BFRed stubbornly refused to use the texture I told it to use (called shivan-beam.*), and instead it used that mentioned beam-white2.* effect, which was originally gray/silver/white - whatever. So, I hoped that the BFRed would be the only one of its kind and promptly I copied the shivan-beam.* effect and renamed it to be beam-white2.* ...

Now the situation is that effect named "beam-white2.*" is equal to shivan-beam. And if there are other "stubborn" beams that don't want to behave as they are told to behave and also use the beam-white2.*, they too appear red.


It seems like we have to define WHY some of the beams want to use beam-white2.* instead of the effect pointed to them... So, BFRed is one of these. What are the Deimos' beams called? LTerShlash or TerSlash?


Well, here's the table entry for BFRed as it is now... Can you see from that why BFRed wants to use beam-white2.* instead of shivan-beam.*? I suppose that if we can find out why this happens, I can fix the other similar errors too.

Code: [Select]

#Primary Weapons

//Other entries

$Name: BFRed
+nocreate
$BeamInfo:
+Muzzleglow: beamglow4
$Section:
+Index: 0
+Width: 165
+Texture: shivan-beam
+RGBA Inner: 0 0 0 0
+RGBA Outer: 0 0 0 0
+Flicker: 0.1
+Zadd: 2.0
+Tile Factor: 33.0, 1


$Section:
+Index: 1
+Width: 50.0
+RGBA Inner: 255 255 255 0
+RGBA Outer: 0 0 0 0
+Flicker: 0.1
+Zadd: 1.0
$Section:
+Index: 2
+Width: 0.0
$Section:
+Index: 3
+Width: 0.0
$Section:
+Index: 4
+Width: 0.0


//Other entries

#End


It should use shivan-beam, but it doesn't, for some reason.

[Wanderer]

If you are using mediavps you ought to notice that they are full of *-wep.tbm files. Among these (in mv_effects.vp) you can find file named mv_effects-wep.tbm. As this file loads after your beamz-wep.tbm file it simply overrides your the stuff you have written to your tbm.

Also (IMO) you really ought to use several beam sections. For example use still pic with flickering (perhaps 0.2 & Zadd 0) to create the 'background' for the effect, then use animated section (Zadd 1.0 or so) to create movement or some such and finally again slightly flickering (hmm.. 0.1  & Zadd 2.0) still pic of the 'solid white beam core'

[Herra Tohtori]

I thought about it.

The thing is that I have already constructed the animations so that they consist of three layers: there's a "bottom" layer indeed, then there is a bilinear gradient beam core, and on top of that there is one more layer that puts some... disturbances over the beam core.

Beneath this texture layer is, though, a simple white layer positioned behind the beam's brightest part. This should ensure that the beams look bright white at the center even when they are viewed agains dark background.


Of course I *could* make an animation for the bottom layer, still texture for the light bar around it, and a second animation for the third texture, but that would just use twice as much space and memory, and the effect would be initially same-looking.

I'll check what I need to edit in mv_effects-wep.tbm... that must be the cause for erratic behaviour in this case. Thanks.

[Wanderer]

 :

Also (IMO) you really ought to use several beam sections. For example use still pic with flickering (perhaps 0.2 & Zadd 0) to create the 'background' for the effect, then use animated section (Zadd 1.0 or so) to create movement or some such and finally again slightly flickering (hmm.. 0.1  & Zadd 2.0) still pic of the 'solid white beam core'

What i mean is that you really ought to use multiple beam sections (with still pics) in addition to your animated section with the Zadd values to enhance the illusion of 3d beam.

[Herra Tohtori]

Okay, let's consider:

-If I put a still image beneath the animated texture, it'll not show itself very much if at all, because the animated section is on top of it.

-If I put a still image on top of the animation, it partially hides the animation, which already has three layers to boot with, embedded into animation frames.

Though, a still image behind the animation might take care of some of the brightness issues. I can try, but I don't see how it would increase the 3D impression very much.

--> to test...

[Herra Tohtori]

Modified Beamz v1.1

Some changes to beam styles, though they are still not completely finalized.


On my PC, the beams - particularly terran beams - become somehow... "cut" into pieces when you move your viewpoint along the normal of a beam... anyone else getting this?

[neoterran]

Nice fixes, and quickly ! Alright. Upgraded, really loving these textures.

One thing i noticed with the Shivan beams is as you move along the viewpoint of the beam the center part becomes super bright and then fades back again, which i think adds to the realism of the beam. I'm pretty excited to see what would happen to the way these beams look once the pixel shader code gets added... one of the only problems now is the sharp clipping with bright objects, which a bloom shader does a lot to soften and minimize and make look more realistic.

I think these beams are great because they add detail and differential while still keeping the whole "freespace 2" feel.

[neoterran]

Hey, you've got a problem with your 1.1 file. You've removed too much of the beam-white I believe, because the Shivan beams look all wrong now. If you intended them to look like that, it looks really bad and I think you should go back to what it looked like before. I think you're going to have to add some of the files back and make it a 1.2 release.

Another thing you should really really consider is making these huge TGA files DDS files with nvdxt, which saves memory and looks the same (uncompressed DDS). You hould use the quality_highest flag during conversion.

[Herra Tohtori]

Curious. They shouldn't look that much different than on v1.0

The beam-white2.* files are the only ones that are away... they are completely unnecessary ATM, because none of these beams uses them. The beam-white2.* files in the 1.0 were the exact same, but renamed files as the shivan-beam.* files.

Can you post a screenshot of how the Shivan beam looks like on your installation? Or otherwise, can you describe what you think is wrong, other than it looks terrible?

I did notice something else weird too today... some Shivan craft were using the retail subspace vortex animations. But that shouldn't have anything to do with these beams, no?

Oh, and I haven't had much luck getting nvdxt to work... I rather use GIMP's DDS plugin. I'll give it a look tomorrow after a Java exam...

[neoterran]

if the beam-white eff and tga's are removed, the beams look like this with 1.1 :

http://www.badongo.com/pic/264864

http://www.badongo.com/pic/264865

If i put the beamwhite eff and tga back into the vp from the 1.0 release while keeping your new 1.1 tables, problem is solved.

[Herra Tohtori]

Now I know what is faulty... it's me working with unfamiliar program called VPMage.

I'll just update the v1.1 to have a correct VP file inside it...  Fix on the way.

[neoterran]

Be careful with VPMage... i've seen it corrupt files... use vpview instead...

Beams 1.1a coming up i guess !

The only problem i can see so far is that with the textures you get that weird effect sometimes that looks fake when the beam hits an object and it just sort of ends. I assume that with some pixel shading bloom that effect will be reduced. We'll see, there was supposed to be a test build for it by now that hasn't materialized.

[Herra Tohtori]

Yeah, here be the

Modified Beamz v1.15


It's basically just an error fix, but includes also minimal table tweaks, particularly for AAA beams which sometimes look a bit too grainy since they are so thin. I increased their tiling factor by ten, we'll see what happens to them. I hope this solves the problems.

I tried converting the textures to DDS with GIMP plugin, with quite horrendous results. It looked much the same as the animated GIF beam I posted earlier. Sharp edges and all. *brr*

BTW, isn't VPView just for viewing? I thought you couldn't build VP files with it.

Tomorrow I'll install nvDXT and try if it does any better. Probably does, we'll see about it.


------> sleep.

[neoterran]

you are right about vpview. I've had problems with vpmage for certain tho, it was killing alpha channels on dds files for me. Not sure what a good editor is someone really needs to build one. Maybe i'll whip up a .net vp editor if i can get some info on the vp file structure themselves.

nvdxt should work well, you don't have to use any compression if you use the u8888 mode... so it shouldn't affect quality but it should save some memory.

[neoterran]

Sorry to be the bearer of such bad news : Version 1.15 doesn't work correctly either.

In order to see the beams the way they are supposed to look with 1.15, i need the old table from 1.1 and I need the beamwhite eff and tgas. Otherwise the texure is missing it looks similar to just regular beams.

[Herra Tohtori]

Okay. It seems that FS2 doesn't like my VP solution.

It apparently doesn't want to override the actual mv_effects-wep.tbm located in the mv_effects.vp. That file defines several beams, and when the game utilizes those beams, it still works by the original table.

There's two solutions to this:

Either put the edited mv_effects-wep.tbm into mediavp/data/tables directory, that will override the same named file in the mv_effects.vp

Another solution is to put the mv_beamz.vp into its own directory and put in that directory also a mod.ini like this:

Code: [Select]

[multimod]
primarylist  = ;
secondrylist = ,mediavp368zeta;

That will use the mediaVP's as secondary mod, and the tables in mv_beamz.vp work as primary tables, and the beams work like they should.


I will upload a v1.2 soon, containing updated installation directions and possibly also the tables so that if someone wants to use the VP file from mediaVP directory, he or she doesn't need to grab VPView in order to extract the necessary table from the VP...

[Snail]

Ooh... These beams just made me want to make BoE missions again.

[SadisticSid]

Those beams don't look right to me at all - far too dull. If you have white cores then they should be at maximum brightness. The idea of the originals, to me, is that the light from the core of the beam is so bright that the eye (or cockpit display) can only see it as blindingly white. The falloff corona looks red or green or whatever because the energy level isn't as high on the outer edges of the beam and so doesn't blind you.