Could just be a coincidence, because I've gotten invisible walls without having any errors or warnings during compile and I've had CutNodePortals warnings that didn't cause invisible walls.

But many times I have run into invisible walls exactly where the compiler said there was a CutNodePortals problem.

Either way, I don't think it's a problem specific to Quakespasm. 

CutNodePortals sounds more like something to do with visibility. Any engine folks have any info? 

It's a QBSP warning, I don't recall ever seeing it during VIS. It's generated during the hull building phase I think.

I got tons of them while working on my Jam 6 map, but I fixed all but one. It was outside the playable area, which didn't make much sense to me, so I figured it wasn't worth worrying about. 

Rick - Yes, I've gotten invisible walls and clipping problems in cleanly compiled maps as well. Quake is old and crotchety... 

Some collision issues are the result of bugs in the qbsp code that expands brushes for the clipping hulls. I believe Aguirre or tyrann fixed some if those bugs in their versions of the tools a few years ago. Not sure if there are still such bugs in the current tools. 

I still get clipping issues like the one described above and I am sure I am running the latest stable release that ericw put out 

Just wondering if this has been considered as an addition to this engine? I'm more looking for the ability to have higher vertex precision than anything else because MDL can be rather brutal if you try to add any subtle details on large meshes. Pointy teeth on a shambler would be an example... I've seen a few other now dead Q1 engine updates that added MD3 support to their builds but those are dead and unsupported developments unlike the lovely Quake Spasm. 

in the custom engine thread.

I for one would be over the moon if QS supported md3. Once you start adding long swords and stuff to monsters and big swinging attacks, the .mdl format becomes a real problem. 

backward compatibility is a real issue. the whole point of .md3 is to do stuff that would look terrible in .mdl, so there's not really a decent option to fall back on.

I'm inclined to start thinking about composite models as a way to workaround the mdl vertex butchery, but I imagine that's another big can of worms. 

 

 

I am all for textures with no filtering and even playing at 10fps for the models with or without interpolation... but integer precision is inexcusable in this day and age regardless. Its just unsightly jitters. We support colored lights for that reason. Sure some folks will make a disco map but these features allow for folks that know what their doing the little bit of extra flexibility.

Besides if folks want to keep the oldschool look for their monsters or create them to work with MDL then feel free. I would prefer to not see vertex swimming on my subtle idle animation that has spikes on the back or toothy maw. 

The biggest issue I have is with the vertex precision dropping indeed with bigger models or making animations that take up a bigger volume for limited frames in your models animation frames. Because MDL takes those ranges as the maximum and then scales up the volume of detail that everything else gets. So either you stick to small critters or big creatures with limited range of motion to avoid losing detail. 

When it's just certain animations use a large bounds (eg an attack animation) it can be worth outputting those anims as a separate mdl file and swapping as appropriate in qc. That way your model doesn't get totally trashed because of that one time where he swings his weapon around. 

That sounds like even more annoying hackery than simply supporting a better mesh format... :) 

"Simply" means getting all engine authors on board with the same standard. So, good luck with that. 

I think it would be nice to have the support for it but I really doubt it will be used by most modders. 

Yeah, there are ways to improve the situation a little in the absence of .md3 support, and I think QuakeC "hacks" - such as making a monster from two .mdls stuck to each other (e.g. Armagon), or switching to a different .mdl for certain problematic animation sequences - are less of an undertaking than getting coders to write .md3 support into the engines. 

It's not that difficult. Engine guys love making stuff, you just approach one and ask if he'd be interested in supporting the model you've made. Or even write in the change yourself to a QS fork.

Once it exists, it exists and will get adopted. Same as with any other feature - skyboxes, coloured lights, BSP2 etc. 

I find your optimism appealing and look forward to feasting on it's burnt husk in the future. 

I begged for higher res shadows and .lit2 came and seemingly passed with no real outcome. 

I thought with .lit2 everyone wanted it and then after looking at the actual results we all went "err can you make it blurrier? A bit blurrier still? Actually on second thoughts I'm happy with Quake's original look I guess". 

Not sure how interchangeable the render between quake 1 and 2 are... but I know KMquake engine supports MD3 as a mesh format to use. I for one would LOVE the support of the MD3 format or IQM whichever one is added to the engine builds.

On another note has anyone thought about portal skyboxes like in the original unreal engine? :) That would be fun to build skybox areas that become the levels distant views but with some parallax. 

I would love unreal style portal skyboxes. If that happens though I think alpha on masked textures needs fixing. Currently if you have an index 255 masked { texture it will only alpha as low as .7 I believe. This would need fixing in the main engines.

Also, will someone tell LordHavoc to added masked textures to DP? 

It was the RMQ that first got the ball rolling with fence textures and 2PSB (BSP2).

It's not so much optimism as - if you do it, it will happen, I know because this is how it has happened before when I was involved with feature XYZ.

Complaining that it won't happen because nobody will do it is a self-fulfilling prophecy.