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

[Hendricks266]

DeeperThought, on 19 September 2011 - 08:06 PM, said:

Are you changing sides on this issue, Hendricks266?

No.

Plagman, on 19 September 2011 - 08:00 PM, said:

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.

Yeah.

[Plagman]

Captain Awesome, on 19 September 2011 - 08:15 PM, said:

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.

Please qualify point #1 beyond what "you think", because I can't read your mind. I think it can, and I like to think what I think is closer to the truth than what you think. =)

Point #2 shows how much attention you've been paying to this whole debate; you just chimed in to hate on Polymer but have no idea what's actually going on, nor any actual intention of porting any "projects". To make it perfectly clear, let me reiterate a few important things: the way voxels work in Polymost is by doing exactly this, namely to convert a perfectly good volume set into a polygonal model, resulting in tons of geometry being generated in a suboptimal fashion. What they're asking me is to port this fucked up process over to Polymer. What I'm saying is that it's fucking retarded, and that while I might implement first-class volume rendering capabilities into Polymer at some point in the distant future there's much more critical work to be done first as DT pointed out. Going with the same half-assed hack that Polymost has would be stupid. There's already so much bloat going on in EDuke32, the last thing it needs is (another..) built-in converter that converts all your voxels into models every time you start the goddamn game. If you do the conversion offline, you save tons of CPU cycles when loading the game and it gives you the option to touch up your model after it's done and unlocks a whole range of shit that you're free to not use if you have an old-school fetish, and I respect that since as you said it would be hypocritical to dismiss that on a forum board that talks about Duke Nukem fucking 3D, of all things.

If anything, we should be removing similar idiocy going on in EDuke32. People should convert their MD2s once and be done with it, and we can remove a whole expensive conversion step and rotting codepaths that constantly introduce bugs. The voxel code in Polymost has all these things and then more weird rendering quirks that behave only slightly differently from models, giving more weird shit to modders to think about when they're trying to get things done. All the Polymer model preprocessing crap should also be thrown into an external tool that only does it once instead of taking half a minute spinning your CPU whenever you start the game with the HRP.

[Jimmy]

You're full of shit. I never said I hate polymer, and never implied it. In fact, I actually really like Polymer. That's just your perception. Also, I'm right there with you on the point about optimisation. I'm always down for optimisation. However, when I talk about voxels in the subtext of BUILD games, I prefer the 'compromised' version that basically uses billboarding 'pixel-sprites' if you will, rather than the 'proper' version that uses cubes. I know Shadow Warrior used it that way, and I think Blood did too. Perhaps this clears up anything else I have said.

[Plagman]

Captain Awesome, on 19 September 2011 - 08:59 PM, said:

You're full of shit. I never said I hate polymer, and never implied it. In fact, I actually really like Polymer. That's just your perception.

http://dukerepositor...86.html#msg7286

[Plagman]

Captain Awesome, on 19 September 2011 - 08:59 PM, said:

However, when I talk about voxels in the subtext of BUILD games, I prefer the 'compromised' version that basically uses billboarding 'pixel-sprites' if you will, rather than the 'proper' version that uses cubes.

So you wouldn't use Polymost either then? My opposition is mostly about people asking that I port the Polymost cube conversion code to Polymer since it's "already there". I did say that actual volume rendering would come in the end because it's exciting new tech and always fun to mess with, but that won't be in until everything else is. The little square billboards that the software renderer has got going on is probably the most basic way of going about it, but it's still nowhere as braindead as the Polymost code.

[Tea Monster]

If people want it to look just like it did in 1996, they should get the original CD and a copy of DOSBox.

[DavoX]

This is so obvious that I'm baffled at how people actually miss what is going on... Captain probably prefers Voxels over models because of the tools used to make them, the way they look (come on, making a model that looks like voxels?) and I'm also sure it's because of Captain's preference of Pixels and stuff over more Hires stuff.

[Tea Monster]

The focus for Polymer should be on optimization, not cramming in support for ancient tech.

[Jimmy]

Plagman, on 19 September 2011 - 09:16 PM, said:

http://dukerepositor...86.html#msg7286

Dig up some ancient quote from when I was explicably more of a dumbass.

Plagman, on 19 September 2011 - 09:32 PM, said:

So you wouldn't use Polymost either then? My opposition is mostly about people asking that I port the Polymost cube conversion code to Polymer since it's "already there". I did say that actual volume rendering would come in the end because it's exciting new tech and always fun to mess with, but that won't be in until everything else is. The little square billboards that the software renderer has got going on is probably the most basic way of going about it, but it's still nowhere as braindead as the Polymost code.

I wasn't using Polymost mainly because of many strange graphical inconsistencies between it and the original renderer (though, slowly over time most of these issues were being nixed out until Polymer came around.) However, I never had any reason to use Polymost over the classic renderer. Polymer on the other hand has a whole host of potentially useful things to it. So, unless I'm reading your post wrong, why not import the code from the classic renderer if it's much more simple, and I assume not that CPU intensive?

Tea Monster, on 20 September 2011 - 06:32 AM, said:

If people want it to look just like it did in 1996, they should get the original CD and a copy of DOSBox.

Nonsense. The other side of the coin could say why don't you use some modern engine? In fact, in the case of this particular bit, such an argument is completely stupid because Duke3D never had voxels, proper ROR, or advanced coding effects. However all these things, while somewhat modern can still be used to create an experience one could have imagined in the days of old. Not only that but some people actually like the artistry that smaller resolutions require, it is a much more limited work space and all the more suited to someone's individual art style. Ever notice how Halo and Call of Duty don't look that much more different? However, Blood and Doom have distinct art styles? It's only because smaller resolutions need more room for artistic liberty. I don't play or make games to be 'real life,' but rather to be an artistic interpretation of life or even just complete out-there style fiction. It's more fun and interesting.

DavoX, on 20 September 2011 - 07:51 AM, said:

This is so obvious that I'm baffled at how people actually miss what is going on... Captain probably prefers Voxels over models because of the tools used to make them, the way they look (come on, making a model that looks like voxels?) and I'm also sure it's because of Captain's preference of Pixels and stuff over more Hires stuff.

Pretty much. Voxels fit right in there for 2.5D games, kinda makes you wonder why they weren't more prominent.

Tea Monster, on 20 September 2011 - 01:52 PM, said:

The focus for Polymer should be on optimization, not cramming in support for ancient tech.

Hogwash. If anything voxels are the way of the future.

[Plagman]

DavoX, on 20 September 2011 - 07:51 AM, said:

This is so obvious that I'm baffled at how people actually miss what is going on... Captain probably prefers Voxels over models because of the tools used to make them, the way they look (come on, making a model that looks like voxels?) and I'm also sure it's because of Captain's preference of Pixels and stuff over more Hires stuff.

It's ironic to bust in a discussion claiming that people are missing stuff when you obviously missed most of it.. I never claimed that you should model something to make it look like a voxel, that would be stupid. My point is that you wouldn't gain anything from using the Polymost voxel code over just converting your voxels to models offline, saving a bunch of processing power, opening up tons of possibilities that you may not or may not use, and without further damaging the sanity of the EDuke32 codebase. And of course he prefers voxels because he prefers voxels...

You can't use the code from the software renderer either, because it's from a software renderer. You can't really mix software and hardware rendering like that, which is why implementing voxels _properly_ would require more work than the copy-of-pasting of code that people have been nagging me to do. I believe prioritizing that work before other more critical stuff would be ill-advised.

I'll try to make it clearer:

• People want voxel support
  
• I tell them it won't be for a long while because it's pretty much the last thing on my list
  
• They tell me that Polymost already has voxel support so why can't I just copy-paste that code and be done with it? That can't be that much work, right?
  
• No, because this code is inferior to just converting your models ahead of time in _every_ way. You should really do that in the meantime, you'll get all the features of Polymost voxel support and more if you want them.

I'm not trying to dismiss people who like voxels as silly even though it's personally not my thing. Tea Monster is very right that the way of Polymer is the future. That means that volume rendering will be implemented properly and using the latest techniques. Using the code from Polymost would just be a step back and again, it wouldn't provide anything over just converting your voxels to MD3 ahead of time, just take things away. I hope that's clear now, because I've been yelling that at the top of my lungs for the last 15 posts or so.

[Hendricks266]

Plagman, on 19 September 2011 - 08:34 PM, said:

the way voxels work in Polymost is by doing exactly this, namely to convert a perfectly good volume set into a polygonal model, resulting in tons of geometry being generated in a suboptimal fashion. What they're asking me is to port this fucked up process over to Polymer. What I'm saying is that it's fucking retarded, and that while I might implement first-class volume rendering capabilities into Polymer at some point in the distant future there's much more critical work to be done first as DT pointed out. Going with the same half-assed hack that Polymost has would be stupid. There's already so much bloat going on in EDuke32, the last thing it needs is (another..) built-in converter that converts all your voxels into models every time you start the goddamn game. If you do the conversion offline, you save tons of CPU cycles when loading the game and it gives you the option to touch up your model after it's done and unlocks a whole range of shit that you're free to not use if you have an old-school fetish, and I respect that since as you said it would be hypocritical to dismiss that on a forum board that talks about Duke Nukem fucking 3D, of all things.

If anything, we should be removing similar idiocy going on in EDuke32. People should convert their MD2s once and be done with it, and we can remove a whole expensive conversion step and rotting codepaths that constantly introduce bugs. The voxel code in Polymost has all these things and then more weird rendering quirks that behave only slightly differently from models, giving more weird shit to modders to think about when they're trying to get things done. All the Polymer model preprocessing crap should also be thrown into an external tool that only does it once instead of taking half a minute spinning your CPU whenever you start the game with the HRP.

Plagman, on 19 September 2011 - 09:32 PM, said:

So you wouldn't use Polymost either then? My opposition is mostly about people asking that I port the Polymost cube conversion code to Polymer since it's "already there".

Plagman, on 20 September 2011 - 03:04 PM, said:

My point is that you wouldn't gain anything from using the Polymost voxel code over just converting your voxels to models offline, saving a bunch of processing power, opening up tons of possibilities that you may not or may not use, and without further damaging the sanity of the EDuke32 codebase. And of course he prefers voxels because he prefers voxels...

I'll try to make it clearer:

• People want voxel support
  
• I tell them it won't be for a long while because it's pretty much the last thing on my list
  
• They tell me that Polymost already has voxel support so why can't I just copy-paste that code and be done with it? That can't be that much work, right?
  
• No, because this code is inferior to just converting your models ahead of time in _every_ way. You should really do that in the meantime, you'll get all the features of Polymost voxel support and more if you want them.

I'm not trying to dismiss people who like voxels as silly even though it's personally not my thing. Tea Monster is very right that the way of Polymer is the future. That means that volume rendering will be implemented properly and using the latest techniques. Using the code from Polymost would just be a step back and again, it wouldn't provide anything over just converting your voxels to MD3 ahead of time, just take things away. I hope that's clear now, because I've been yelling that at the top of my lungs for the last 15 posts or so.

Dropping MD2 support makes sense for the future but mods will break. That doesn't concern me.

I am concerned about the Polymer preprocessing. It's important that exported MD3 files be able to be re-imported to make modifications and renders, especially if the source is lost. Speaking of which, MD3 support should be dropped too for something more modern.

I understand your point of view on voxels. I will never ask you about them again. I will work to write an on-the-fly converter for EDuke32 which is optimized in code size, conversion time, and in-game performance. That is the solution, especially so that future optimization improvments can be applied to the voxels, and because this will need to be done for Blood and Shadow Warrior anyway. However, if I fail, volume rendering will come eventually.

Tea Monster, on 20 September 2011 - 06:32 AM, said:

If people want it to look just like it did in 1996, they should get the original CD and a copy of DOSBox.

Looks are not everything. I could write a long list of everything added to EDuke32 and even the Polymer renderer that are not specifically related to highres textures and 3D models. Performance, mouse aiming fixes, resolutions, stability, modding...

Captain Awesome, on 20 September 2011 - 01:55 PM, said:

Hogwash. If anything voxels are the way of the future.

I side with Plagman on this one. 256 color palette-limited, 256x256x256 KVX files are not the way of the future. They are, however, a defining characteristic of BUILD.

[Plagman]

I don't understand your concerns about Polymer preprocessing. The MD3 file would still be there, you'd just have to re-process it if you modify it.

You say your understand my point of view but claim you want the conversion to happen on-the-fly. Please let it be standalone.

Hendricks266, on 20 September 2011 - 04:31 PM, said:

Speaking of which, MD3 support should be dropped too for something more modern.

This also bugs me greatly, as lots of people like to jump on that bandwagon. What do you propose as a replacement? What exact benefits would it provide? If you say skeletal animation, that's wrong; you'd implement support for a model format that has skeletal animation _because_ you implemented support for it in the engine beforehand, not the opposite. Implementing MD5 support before a complete rewrite of the animation system would be a step backwards since you'd have to pre-render all the animations to static meshes.

If you say the lack of tools because MD3 is growing old WRT community support, I maintain an MD3 exporter and ASE importer for Blender for that exact reason.

[Mark]

After reading about converting MD2's to MD3's I checked my Eduke folders and did not find any MD2's. They must have all been converted already. So I guess only older mods would be broken.