Someone took a bite already : -(

I think with a bit less laziness it would be possible to make something that looks a bit smoother as well. In the zip the effects are produced by
1) Randomising each vertex from the whole range of 162
2) Randomising over the first 15 vertex normals on a per vertex basis
3) Randomly selecting one vertex normal per frame and applying it to all vertices
4) Randomly selecting one of the first 15 vertex normals for all the vertices in a frame

They all rely on essentially random selection of vertices because I was too lazy to import the table and start doing dot product calculations. With a bit more work you could create effects that vary continuously through space and across frames. 

dude, that's awesome!
how are you randomising the normals like that? can it be applied to anything? i'd love to get that effect going on an fx model i'm using. way better than just flickering alpha! 

I've uploaded one of the 4 perlscripts I used to make these models at
http://www.btinternet.com/~chapterhonour/randnorms.pl

It's a hacky thing I wrote when I was learning perl, there's at least one thing I do which is not best practice. It also hardcodes the filename it operates on(currently gem.mdl) because at the time I didn't know how to parse command lines. On the plus side it doesn't need the perl library I wrote for operating on models, it's stand-alone.

Soon I'll be recreating that library in python because it turns out that perl syntax isn't very readable. When that happens I'll try and create a more readable python script to do the same thing. 

Just a quick thought, when I see any container of red liquid which refills health, I myself tend to think of it as a potion and thus would be rather potent. With my mind coming from that angle, even the smallest healthkit looks like it would have the impact of a megahealth (with the largest looking like it could heal an entire party in coop like a mega). Essentially, all of these look like they would deliver a lot more health than they would running stock qc. 

hmm yes, i think i agree with that /\

what if the rotten and normal kits were closer to the size of the Hx2 flask? (this one: http://lparchive.org/Hexen-II/Images/16-hexen2-items_flask.gif )

also: preach, that script works perfectly! should be noted (and in retrospect i should have realized) that you can't use fullbright colours on the skin otherwise the lighting effect isn't applied.

still, works well and looks very cool. thanks! :) 

That gem looks good n game, Preach although it's a mystery how you obtain the effekt.

Here is the tessla coil.
http://members.home.nl/gimli/tessla.zip

Don't get burned. 

If you are using darkplaces then you will also notice the effect appears to cease working. Now we are sort-of performing a hack here so it isn't that surprising that response is mixed. It's also worth noting that what darkplaces is doing is not entirely terrible(tm).

Lets break down why in most quake engine we get varying brightness by changing vertex normals. I believe this is accurate but correct me if you know better...Quake has effectively a hack to make vertex normals work, by rendering as if there is a single bright source of light coming from a fixed direction. You get brightest light levels by having a normal directly facing that direction, and darkest by facing away from it. You can observe this by rotating 360 degrees on the spot and watching the shading vary on the viewmodel.

Darkplaces rejects this and instead uses all sources of dynamic light in the scene as origins for vertex normals to be evaluated against. This means that the twinkle effects are not visible most of the time, but if you run the quad cheat you can get them to render. 

yeah, that was the first thing i checked after seeing it work in QS. :)

of course, if you're running in DP, it's not much extra work to include a q3 shader script to take the place of the flickering vertices. 

don't know if everyone knows this already; this is mainly useful if you're just modding an already made model:

if you convert a .mdl in a .md2 with q2mdlr9b and export a frame, you will be able to import the md2 into max (with http://www.scriptspot.com/3ds-max/scripts/quake-ii-md2-importer ) whil preserving the original q1 skin mapping.

from there you can add to the uv map with normal max tools and then export following the md3 -> mdl route. nice not to have to start from scratch. 

Missed 30 odd posts there.

Did you get an FBX exporter or workaround Necros? As far as I can remember I'm using the default one from Max2010.

Those pickup models look great - we also did this, but ours are fairly un-artistic :( 

nah, couldn't figure it out.
i've since gotten an alternative method which works fine using npherno's md3 importer and preach's md3->mdl converter. 

Recheck my export method when I get home anyway, haven't looked at it in a while. 

After adding the robot arm in my map I see this strange overlapping effekt of the cellbox.
In the framegroup there's nowhere a cellbox sliding diagonal, but in game there is.

http://members.home.nl/gimli/Cclaw.gif
http://members.home.nl/gimli/cclaw.jpg

Whayt is it that makes the cellbox warp? 

Interpolation? 

This example shows the effect, now the solution if there is.

http://members.home.nl/gimli/celbox.wmv 

That looks like interpolation. :) Try turning interpolation off in your Quake engine and see what it looks like. 

looks fine to me? what am i missing? it picks the box up and moves it over, then drops it again. also looks cool. 

i see it in the video. How to fix it depends on how this animation will be integrated into the level -- obviously right now you have one box vanishing an another magically appearing, so this isn't a complete thing yet. 

oh the playback must be broken as it freezes half way for me.
you could try adding two frames, one at the end of the sequence where the boxes shrinks into itself into a single point, and one at the start where it grows from a single point. this way, it would lerp the movement of an invisible single point.
it'll still look goofy because you'll see the box grow and shrink really fast though. 

The animation is a 30 frame static entity, that is a part of two combining conveyor belts.
In the middle there would be another one with an injector uploading the cellboxes.
For one animation the frames are too complicated so I make them in three parts.

The bad point is that I have to make them fit to eachother in place and time.
So the interpolation willem directed to is the cause. I tried to add interpolation 0 at the console but that's wrong ofcourse.

I keep hearing the word lerping.
In the gif file the last frame is the cellbox at the end.
There will be a counterpoint both boxes are on the same place, but I thought I could catch that by letting them drop down into a solid brush while they are moving backwards. 

I found the fitzhack version to temper my intention to make the interpolation for the static entity. I just didn't knew it was the engine that had this limit.

The animation rolls much more shaky, but fills in the exact rotation.
The original fitzquake rolls much smoother, but then I keep the hazy frameshades.

I think I keep on to original Fitzquake, as for now only the wheels get creepy.

http://members.home.nl/gimli/vey00.jpg
http://members.home.nl/gimli/vey01.jpg 

http://members.home.nl/gimli/convey.gif 

It soon became clear to me that tuning two static entities is a real framejerk, so I combined them.
Reduced the interpolation effect of the conveybelt to the wheels, and then noticed the swing in the middle.
It had become a jolly cellbox.
In Qmle it won't show but in game it's hardly a count.

http://members.home.nl/gimli/conveyc.gif

http://youtu.be/OAi_Sj74BP4 

So is it 1000 verts, 2048 tris? I have a model with ~1700 verts loading just fine.