[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.

[Tetsuo]

Well I've been getting the latest SVN code to compile every time I notice changes in SVN but full screen doesn't work yet on my Lion OS X with ATI card... but everything else seems OK.

[Plagman]

 3D Master, on 12 September 2011 - 12:11 AM, said:

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.

Yes, volume rendering is definitely the future. However, the way BUILD lets you do it is just a tiny subset of models, so of no relevance here. Also, you're very naive if you think this isn't GPU-accelerated. Graphics hardware is programmable enough to be able to pull that off these days.

[Plagman]

 Tetsuo, on 12 September 2011 - 12:23 AM, said:

Well I've been getting the latest SVN code to compile every time I notice changes in SVN but full screen doesn't work yet on my Lion OS X with ATI card... but everything else seems OK.

Things like fullscreen and mode management are handled by SDL rather than code in EDuke32 itself. Maybe the prebuilts from rhoenie used a different frontend than just the stock SDL one? Do you still get the fancy Mac startup window with your built binaries?

[Tetsuo]

Nope, I don't get any startup window... Also, what I did was I built the binaries and then replaced the ones in the .app file from Rheonie.. up until recently the fullscreen worked just fine this way when others would build the game like Helixhorned. Now when I try to set it it says failed even when I try to start it up in a window and THEN switch to full screen via alt+enter.

BTW, all the .app file is is a folder with a certain structure with a .plist file that defines the executable to launch when you double click the folder.

Unable to set video mode!
Failed setting fullscreen video mode.
Load tile 2492: p0-m4-e0 highres/screen/menu/2492_ver.png... 37 ms
PR : Failed to compile GPU program with bits 528449!
PR : Compilation log:
2ÂÌ¥
PR : Vertex source dump:
2ÂÌ¥
PR : Fragment source dump:
2ÂÌ¥

Is what gets spammed in the log... btw.

Running the binary by itself makes no difference.... I just tested that out. I even tried pulling the binaries out of the .app folder structure but that makes no difference to the fullscreen either.

I downgraded it to the last build Helixhorned had uploaded (eduke32-osx-1934) and fullscreen works there. The downside is I don't get the other fixes by running an older build.

By the way I wasn't getting the startup window with Helixhorned's build either.

[3D Master]

 Plagman, on 12 September 2011 - 06:42 AM, said:

Yes, volume rendering is definitely the future. However, the way BUILD lets you do it is just a tiny subset of models, so of no relevance here. Also, you're very naive if you think this isn't GPU-accelerated. Graphics hardware is programmable enough to be able to pull that off these days.

Letting the GPU run a software renderer isn't hardware dedicated to voxel rendering.

[Plagman]

You won't ever get that; there's less and less stuff dedicated to polygons left in modern graphics hardware, but that doesn't make polygon graphics less hardware accelerated. Generic progress will be made that will enable volume renderers to be faster and more powerful, but you won't get "voxel accelerators". You already have SVO raycasters running efficiently on the GPU, utilizing them to their full capacity; I don't know why you'd call that software-rendered. By your logic, should we call anything that uses shaders software-rendered because it runs on programmable hardware?

[DukeFTW]

Looks awesome as always.

[Plagman]

I committed a fix that enables backface culling for models. That should buy us some performance overall, but most importantly fix the visual glitches that people were experiencing with certain models (WGR2 fence). However, the HRP fence needs to be fixed to be facing the right way. I think it was Roma's model?

[Hendricks266]

 Plagman, on 17 September 2011 - 11:21 PM, said:

However, the HRP fence needs to be fixed to be facing the right way. I think it was Roma's model?

Yes, it's Roma's model. He also needs to modify it for these three tiles from Nuclear Winter:

-->

/hijack

[Roma Loom]

mkay

[Jimmy]

 Plagman, on 11 September 2011 - 09:47 PM, said:

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.

You misconstrue my post. I actually had an interest in shifting the project toward Polymer, but I was waiting on implementation of voxel support. I plan for voxels to be a mainstay of the visuals for the mod. I value their graphical appearance, and that is the reason to use them over models. Models aren't pixellated as voxels are.

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

Voxels? Dude, this is the 21st Century!

Duke Nukem 3D? Dude, this is the 21st Century!

[Plagman]

That means you missed my point, then. If it's the graphical appearance you're after, you can have models that look exactly like voxels. However you can't have voxels that look like models. That's why models are a superset of voxels: they can provide everything that voxels can, and more should you need it. If you don't need/want it, you're free not to use it. You can have something Polymer-based that looks like that if that's what you're into:

[Jimmy]

I don't know of any KVX to MD3 converter, but you're welcome to show me one.

[Hendricks266]

One more factor I haven't mentioned before is that you can enable and disable voxels separately from models and textures in-game, which is something that you will lose if we are forced to define voxels as models.

BUILD Engine History:

Quote

01/29/1996: Duke Nukem 3D 1.0 Released
02/08/1996: Added VOXEL support (.KVX files)

[Plagman]

Your first point hardly matters, and your second point.. why does it seem like you're trying to prove that I'm supposed to implement voxel support while I've already stated numerous times that I wasn't going to? It doesn't seem like a good use of your time; why don't you go and write a KVX -> MD3 converter? This way everyone will be happy, and the logic you need is already all in polymost.c.

[Danukem]

Are you changing sides on this issue, Hendricks266?

My view is that while voxel support would be nice -- if it could be implemented in a way that wasn't horrible (an important qualification that Plagman doesn't think can be met)-- we can live without it and there are more important things to worry about:

http://forums.duke4....dpost__p__88492

 Plagman, on 31 May 2011 - 09:39 PM, said:

Things that needs to be done:
- Move the diffuse modulation from the material to the vertex attribute. That would cause the amount of different materials in a map to be all the different tiles used, instead of the more complex tile X shade.
- Move plane vertex attributes from several unique vertex buffers to a single storage or several depending on the staticness of the data.
- With a more reasonable material count and stuff sharing buffers, we can start batching planes together. To leverage that, throw planes into material buckets instead of rendering them right away. When we're done building index buffers for the buckets, submit them in one big go (one per material).
- Change the HSR walking to do a first pass before doing the actual shaded drawing. This means that in the event that occlusion queries have to be reaped, we can get the result a lot faster since we're pushing a lot less pixels using a passthrough fragment program.
- For rendering the shadow maps, we only need materials for sprite silhouettes. The rest can be batched in a single draw call after building the right index buffer, same as above. This will be a lot faster.

(Even) bigger projects:
- Defer the lighting model to shade from a fat buffer instead of inline. This eliminates two very expensive steps, light culling and multi-pass drawing.
- Instance models together.

The importance of the Polymer overhaul dwarfs the importance (if any) of adding voxels to Polymer or anything else Polymer related we talk about around here. If it doesn't run well, then the other stuff is moot. Having said that: yes, it can be made to run well right now, but it takes a decent rig and maps that aren't very complex and/or don't have lots of lights.

[Jimmy]

And actually, thinking about it, I don't think an MD3 could properly convey the appearance of a voxel, nor would it's application be optimal for the engine. Me thinks a small voxel would take tons and tons of polygons to look proper.