use binary? An unsigned int with a max val of 127 needs 7 bits. So you can store 4 o these in a 32bit float and still have 4 flags. 

of course... all you get is more flags. :P 

By golly, you're right - i can assign a hex code to a float in quakeC to make full use of all those bits right? I forgot i could do that... 

i'm a tard - i'm thinking of literals. Not sure how i'd manipulate the bits of a float in quakec programmatically. 

You best ask Preach about such things. Necros, I thought Kinn was only encoding two values into a 32bit float. With binary encoding, you get four numbers plus four bits. 

i was just commenting on the flags in general.
no matter how many you have, they're still just bit flags.
you can't save monster positions or anything like that, which for me is the real draw of trying to save information. 

 

Well, it's possible, and if you really wanted I could look around for the code because I know somebody else has done the legwork already (probably Frikac). But the basic idea is just to learn everything about how IEEE 754 floats use the 32 bits in a floating point number and then reverse engineer it bit by bit (no pun intended).

So you'd start by reading the sign of the number, which gets you one bit. Then you calculate the size of the exponent which gets you 7 bits*. Using the size of the exponent you can then multiply by an appropriate factor to get a integer stored in float form with 23 bits of value you can read off in the usual qc way.

*The exponent of a IEEE 754 float is actually an 8 bit signed char, but setting it to 128 indicated the special values like infinity and NaN. Consequently you can't encode or decode the mantissa of those floating numbers, so you have to limit yourself to 7 bits. This also luckily allows us to completely avoid the topic of subnormal numbers by sticking in the range 64 to -63. 

Well, it's possible, and if you really wanted I could look around for the code because I know somebody else has done the legwork already (probably Frikac).

Cheers, if it's easy for you to find I wouldn't mind taking a look at it, but I'm far from being at a point where I need it right now.

All I was thinking of doing was storing a load of level state flags that persists across the multiple levels of an episode, and I reckon I could do that easily with the couple of hundred flags I've already got access to via the unused parm variables without needing to compress the already used parms too much, if at all. 

Scrounged that code you wanted out of the Prydon Gate codebase, a mod written by Frikac, although some of the comments suggest LordHavok had a hand in writing this portion of it. So I take no credit for the code, and in fact have never tried to use it. Nonetheless it looks fairly well devised, the functions split the job into digestible chunks, and the comments describe the restrictions.

The extra nice bonus I failed to recall was that this bit of code is already being used for data storage in parms - I only remembered the decoding of floats. Have fun...

http://www.btinternet.com/~chapterhonour/parms.qc 

that's bloody top shelf. Cheers mate :} 

has anyone tried using triangular pyramids instead of triangular prisms for trisouping?
allows a lot more freedom (almost like working with individual faces!) at the expense of a bit more work.

...or does everyone use pyramids now? 

Most people use pyramids now. Just banging some terrain together only needs triangles, but they tend to produce bugs.

Of course, there's always: http://nemesis.thewavelength.net/index.php?p=8 

Most people use pyramids now

this sounds messy - do you have any links to examples? 

Not really - and yeah, it can potentially be a mess.

I can post a couple of test maps later on if you like. 

i shouldn't bother unless you've already made something - i doubt i can be swayed from the path... 

yes, it's quite messy in the viewports. 

We've got a test folder full of odds and sods, there's definitely at least one or two examples in there.

Can't check from the office though. 

So. what are all the cool kids using these days to turn a Maya animation into a Quake .mdl? 

just found the modelling help thread.

Lunaran to the rescue it would seem :} 

If Noesis is mentioned on there:

http://oasis.xentax.com/index.php?content=downloads

Which is a multi-multi format that also supports Quake stuffs. Could be a decent alternative. 

More options can't be a bad thing, right? My current favoured method is to export to MD3 files, and then compile them into Q1 format using md3tomdl. I like calling it compiling because it suggests the same kind of workflow as iteratively tweaking/compiling/testing a map. It also makes the process sound irreversible, so that you always keep the model editable in a more suitable format. Like keeping your master recordings in wav files rather than converting them from and to mp3 each time you want to remix... 

I prefer to hit less steps on exporting to be honest - Quake can be pretty finicky about exporting and the more steps there are the more likely things are to screw up.

And its more work.

I'm still using Qme for many things, which can throw a wobbler every now and again and refuse to work.

Holy shit I'm disagreeing with Preach. 

The way I look at it is that it lets me cut out the step which involves QMe entirely. Before I'd get the model geometry designed and animated in gmax, then do the conversion and finish off the model in QMe. Usually the finishing off is just stuff like rotating and scaling properly, handling the skin.

The problem I had was that then if I realised I wanted to make some deeper change to the model, like un-mirroring a section of skin or adding extra detail to the mesh, it would mean ditching all that work in QMe and going back to the gmax version. So for me running an extra batch file to compile and copy the model to the right place is a timesaver, but it depends on your workflow.

(PS: cutting out QMe means you can use smoothing groups on your mesh!) 

(PS: cutting out QMe means you can use smoothing groups on your mesh!)

Quake's model lighting uses smoothing groups??