thanks for helping me understand this mfx/rebb.


So yeah, the latest test version lets the map compile but what exactly is this winding stuff?
From what I remember when I briefly dabbled in 3D and openGL stuff, winding is some kind of method of storing your vertices and faces in memory...

I guess I'm asking how can I avoid doing this?

Too many faces share the same plane?
I think someone once said that there is a limited number of planes than can be used in one map, but that if you have faces with the same plane, it'll reuse that plane or something..?


Also rebb: texture offset for rotating objects!!!!!!! <3 

Thanks for the feedback. I haven't really tested in multiple browsers yet, but I'll check that out next time I work on it.

Not sure how I can fix the texture problem though, I noticed that myself but since the uvs are just generated from the bsp data I have no idea what is causing the problem. There are also some limitations with webgl, so any non-power of two textures could potentially cause problems depending on the system.

The bsp preview isn't really meant as an accurate bsp viewing tool though. Would be nice to add lightmaps and have a few display options though. 

extensions appear to be case-sensitive, meaning it'll refuse to load files copied off a fat32 drive (FOO.BSP).
no error message from trying to load q3/rbsp/bsp2 maps.
clicking files within a .pak doesn't seem to do anything (firefox).
it doesn't recognise .qc!
mdl rendering consumes an entire cpu core even when not given user input. 

thanks. I'll look into all those things.

Not sure what I should do with .qc files... What would you like it to do?

Firefox doesn't seem to handle the file url the same as chrome, since I'm not generating a data url until the user clicks a link, which basically equals me auto downloading a generated file for the user - perhaps it's a security risk? Anyway, chrome allows you to extract files currently, but I want to make it able to modify paks at some point.

Anyway, it's currently very hacky (esp. rendering), so I will fix some of this during the next code cleanup. 

Thanks a lot for this rebbor!! 

I have a vague recollections that windings are to do with the number of sides a polygon has. Do you possibly have a face anywhere with more than 64 edges? Perhaps not intentionally, but if you had lots of adjacent planes that nearly meet at the vertices but actually cut tiny slices, that might create one.... 

I'm not exactly sure what you mean. How could a face have 64 edges? They are all triangles. Or do you mean one plane that has been divided more than 64 times? 

In fact in glquake they're still polygons when passed to OpenGL. Just for fun I checked start.bsp and it has a 20-sided poly somewhere!

So "r_showtris 1" is a bit deceptive; it shows you the polygons as they come out of the bsp, plus a bunch of lines drawn in to divide them into triangles, but you can't see which lines are which. 

r_drawflat shows polygons. 

Windings are used in a lot of places in the code, also for portal generation. I think mfx managed to find a version of your map in your house while you were sleeping online and it had a very large ring-like structure in it with a lot of side elements.

If a portal is generated inside this, it can easily go over the 64 point limit and cause this error to be thrown. 

Breaking limits since 2003! 

Once you've found places where that happens, shouldn't it be possible to use a hint brush to break that ring in half/quarters/etc so that can't happen? 

Necros, the file flew by on the TB issuetracker, had to grab it to reproduce the error.
I also had no luck with epsilon values being changed slightly, but the hint/skip support of the above mentioned compilers should be able to eliminate the error.
Without having to raise the max_windings of course.. I keep you updated.

Sorry for any inconvience caused:) 

Cool, ok, so it is fixable then... Yet flying around in the map didn't show me anything obviously having tons of edges. Some faces had maybe 6 or 7 sides, but most were split up to 4 or less sides.

and it had a very large ring-like structure in it with a lot of side elements.
Not sure which map you're talking about, but this is a new one with a very similar concept. It is a large ring of windows. So since I don't see any faces with a lot of edges, it sounds like it must be this case where a portal is being generated inside this ring. 

I've built a demo smoothing utility for DaZ, and even though I suppose it's of limited use, I'll post it here anyway in case anybody is curious and in order not to give any particular youtubers any unfair advantages!

http://mandelmassa.net/quake/demsmooth-1.02.zip

The binary is a 32 bit Windows build made with mingw32-gcc in cygwin. Source is here:

https://github.com/mandelmassa/demsmooth 

this is the method used to get the smooth camera movement? 

I think DaZ has used it in some of his latest Quake videos, for the intro bit. That's what it's intended for! Using it on regular play demos might render unexpected results since it's tuned for slow movement. 

I just converted one of my normal play demos with it and it looks like I'm drunk or stoned playing. 

It was made in response to the now classic january 1st W00tles post! 

That's a very cool utility! I thought he was placing waypoints or somesuch, but this method of doing a flyby camera is way more intuitive and simple! 

Fixed a bug with parsing Fitzquake spawn baseline messages - the program couldn't parse my own jam2_mfx demo so I just had to debug it.

http://mandelmassa.net/quake/demsmooth-1.03.zip 

Mandel, please write Quaddicted a demo meta data extraction tool for 15, 10002 and 666. Something that extracts statistics like kill/secret count, length, completion, skill, maybe even shots fired or distance tracked if that is possible. Thank you! bye! 

I just might! 

In triggers.qc:

void() teleport_use =
{
self.nextthink = time + 0.2;
force_retouch = 2; // make sure even still objects get hit
self.think = SUB_Null;
};

the purpose of force_retouch is clear, but I've always wondered why a teleporter had to have its nextthink set just to do nothing. Is that more obtuse secret qc behavior related to how force_retouch works? Or just cruft? 

beware of force_retouch! it breaks trigger_hurt!

anyway, the touch function:
if (self.targetname)
if (self.nextthink < time)
return; // not fired yet

it uses nextthink as a random timer for some reason. just weird code. there's no special engine magic needed here, just the sub_null thing to stop the engine complaining when it does try to do its think magic.

it should have used attack_finished...