[Kyanos]

Plagman, on 31 August 2011 - 08:33 PM, said:

That's because you're trying to set up parallax mapping with huge factors; your height map probably isn't anywhere close to correct looking at these shots.

I figured it was something I did. I just wanted to show you in case it was a polymer issue. And the height map came from that crazybump program, so it's probably flawed somehow, they base it from a picture. I will make my own and hope for better results. Thanks Plagman.

[MusicallyInspired]

TX, on 28 August 2011 - 11:31 AM, said:

I guess nobody posted about this here yet, but Plagman fixed the huge problems ATI users were experiencing with Polymer last night. Go Plagman.

Hooray! Congrats, Plagman! Not that it matters to me anymore. I've since upgraded to a NVidia card with no issues at all. But this will be a godsend for people still living under ATI's regime. Thank you for all your hard work!

[Kyanos]

So Plagman, I've come across another issue with the same model as yesterday.

DeeperThought, on 01 September 2011 - 12:50 PM, said:

I did some more testing. The shimmering bug only happens in Polymer. It happens regardless of whether the normal is being used, so the normal is not causing it. Apparently it is a Polymer glitch.

I am attempting to replace a set of fence tiles with this one md3. The model has 2 planes in the center, each facing opposite directions. These two planes are what change for each different sprite via separate skins. This is the area DT is talking about in this quote. Both planes coexist at the exact same location, just a mirrored duplicate. I will try some adjustments on the model. I just wanted to let you know about this because it does work in polymost.

[Mark]

I don't want to turn this into a modeling thread so I will post my response over in the other WGR section. I'm pretty sure I know what the problem is with the model itself.

[Danukem]

Is synthesis taking an abnormally long time to get updated with the latest snapshot? As of this posting, the latest revision in there is r1994.

[Plagman]

A package update on the server broke it for a while; I tried to get it back up earlier today, but failed to fix all the problems. It should be fixed now, the build should be up momentarily.

[Plagman]

And I think that Polymer-specific model problem might just be a symptom of the different backface culling behavior. I'll take a look.

[Kyanos]

Quote

TX, on 28 August 2011 - 02:31 PM, said:
I guess nobody posted about this here yet, but Plagman fixed the huge problems ATI users were experiencing with Polymer last night. Go Plagman.

Thanks Plagman, this fix finally makes polymer playable for me on my laptop

[Tetsuo]

Yeah those fixes also fixed the problem I was having on my eDuke32 although it seems now fullscreen is broken for me for now like I indicated earlier.

[Danukem]

There's a Polymer related bug that no one has reported yet, and I think was recently introduced (I'm not sure how recently, but I started noticing it a few weeks ago...I didn't realize what it was back then and didn't report it).

There is a problem with floor aligned and wall aligned sprites not being displayed with the correct game palette when the game palette changes (e.g. when nightvision goggles are used). I have only seen this happen in WGR2, which has a modified nightvision palette.

-Many wall aligned sprites continue to look normal when the goggles are on, instead of having the altered palette.
-Some floor aligned sprites do have the altered palette when the goggles are on, but then they continue to have it even after the goggles are off.
-In one instance which I haven't been able to replicate, all of the wall aligned wood planks in the map (even those miles away from where the goggles were used) continued to be displayed with the altered palette after the goggles were turned off. Turning goggles on/off again did not fix it. I have a screenshot of this attached.

EDIT: The easiest way to see an example of the bug is to kill some enemies with the rocket launcher while using nightvision ("spirit vision" in WGR2). When you turn them off, some or all of the blood pools will still have the goggle palette.

Attached thumbnail(s)

• 

[Jblade]

anyway to disable Mapster32 spamming it's console with map corrupt errors? It's telling me every level I load has corruptions in it and I've lost track of what keys I have to press to try and fix it or what console commands to use.

[Mike Norvak]

James, on 05 September 2011 - 01:49 PM, said:

anyway to disable Mapster32 spamming it's console with map corrupt errors? It's telling me every level I load has corruptions in it and I've lost track of what keys I have to press to try and fix it or what console commands to use.

Yeah is kinda annoying, anyways you can enter this on the console: corruptcheck tryfix

[Danukem]

Norvak, on 05 September 2011 - 05:40 PM, said:

Yeah is kinda annoying, anyways you can enter this on the console: corruptcheck tryfix

Is there any possibility of that raping the map? It scares me. I just did it on a map, and it changed literally hundreds of sectors. Here's a sample:

 -> auto-correction: reset sector 11's ceiling slope
 -> auto-correction: reset sector 12's ceiling slope
 -> auto-correction: reset sector 13's floor slope
 -> auto-correction: reset sector 14's floor slope
 -> auto-correction: reset sector 15's ceiling slope

The map looks fine, but it's huge and I may have missed something.

[Fox]

I am not sure, but it seems for that is imply removed the slope cstat from sectors with a slope value of zero.

[Micky C]

I think it's to do with a bug that potentially caused slopes sectors to reset their slope to zero, and corruptcheck tryfix prevents that.

[rasmus thorup]

maybe it could have something to do with floorstat and ceilingstat. Maybe if it resets the stat quickly, then the floor or ceiling automaticly sets heinum to zero when the statnum 2 is not set.

[Danukem]

Fox, on 05 September 2011 - 06:25 PM, said:

I am not sure, but it seems for that is imply removed the slope cstat from sectors with a slope value of zero.

That sounds plausible. But that's so minor it shouldn't be considered "corruption". The game could easily fix that at map load time, anyway.

[Helixhorned]

There are two pieces of information about the slope of a ceiling or floor that are stored for each sector: ...heinum determines the amount of the slope, but ...stat's bit 2 determines whether it's drawn (and collision-handled) as a slope at all. If the two are inconsistent, mild annoyances may occur in the editor. I didn't make it run at load-time for the unlikely case that some clever person used heinum as an additional tag.

[Danukem]

Helixhorned, on 06 September 2011 - 01:05 PM, said:

I didn't make it run at load-time for the unlikely case that some clever person used heinum as an additional tag.

Is having inconsistencies between stats and heinum safe, or is it not safe? If it's not safe, then I don't see why the inconsistency needs to be allowed for the sake of a possible tag, especially when there are other ways to achieve the same result (moreover, I doubt that anyone has actually used it that way or plans to). If it is safe, then it's not what should be considered "corruption". When mapster reports "corruption", that sounds very serious; it's too bad there's no easy way to tell how serious the corruption actually is without having a lot of technical knowledge.

[Helixhorned]

OK, point taken. What I'll do then is to collapse all such instances into one. The slope inconsistencies are absolutely harmless, and there is a way to judge the severity of the others: every one has a 'corruption level', which should be read like this:
5 -- run for your life (clearly invalid values that can lead to a crash)
4 and 3 -- very serious and serious
2 and 1 -- warnings
Right now, only the maximum is reported though.

[ReaperMan]

So is there any chance of polymer getting voxel support?

[TerminX]

No, not really.

[ReaperMan]

TX, on 11 September 2011 - 02:46 PM, said:

No, not really.

[Hendricks266]

ReaperMan, on 11 September 2011 - 01:29 PM, said:

So is there any chance of polymer getting voxel support?

TX, on 11 September 2011 - 02:46 PM, said:

No, not really.

[Jimmy]

Well that's a bummer. I have no reason to develop my projects with polymer in mind.

[Danukem]

^Nice.

EDIT that was supposed to be pointing to hendricks266' post

[Plagman]

Captain Awesome, on 11 September 2011 - 08:29 PM, said:

Well that's a bummer. I have no reason to develop my projects with polymer in mind.

If you have no interest in Polymer, why care about it supporting voxels at all? Models _are_ a superset of voxels as they're implemented in BUILD, so there's really no reason to use them over models.

[Hendricks266]

In IRC, it was determined that Plagman will not waste his time with voxels, as predicted by TX the infallible predictor. Plagman should spend what little free time he has doing more important things than voxels. That leaves the responsibility likely to me, so you might be waiting Forever.

[Tea Monster]

Voxels? Dude, this is the 21st Century!

[3D Master]

 Tea Monster, on 11 September 2011 - 11:41 PM, said:

Voxels? Dude, this is the 21st Century!

Voxels are coming back:

http://www.youtube.c...feature=related
http://www.youtube.c...feature=related
http://www.youtube.c...feature=related
http://www.youtube.c...feature=related

Remember; that's all software rendered, since graphics hardware doesn't have voxel support today.