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. 

The limits for verts is 2000 almost everywhere, including dos/winquake. The original glquake binary had a reduced vertex limit of 1000, but the released glquake source had this limit restored to 2000. Consequently every source-port has a limit of at least 2000, and there's no reason at all to keep models at 1000. 

Ah ok, I got confused by the first post in this thread. 

Just thought I'd mention this: preach's md3 converter is awesome. Thanks for making that thing. :) 

I am sure most new content would never see the light of day without the various coder utilities that work away in the background. I am sure preach would love to see what you have been up to with his model converter! :P 

I'm glad it's proving useful, and I'm sure you'll be glad to hear that the next generation of the md3 converter is almost half-done! By which I mean that I've written a module in python which loads and saves mdl format models. I'm just working on a few example models to go with it and then I'll put it out here.

Once that's done, all that remains is to clone the code, adapt it to load md3 files instead, then make the glue code for the conversion. The purpose of all this reinventing-the-wheel is that the glue code will hopefully be clear and easy to adapt, allowing for finer control of the md3 to mdl conversion. For example, if you're making a map object which needs to be aligned on the grid to meet the geometry in the map, you might want to specify the scale used in the conversion of the model coordinates.