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

[Plagman]

Yeah, MD2s were transparently converted for a long while now, but didn't have any usable normals information which made them incompatible with Polymer lighting, so we did a one-time conversion of all the MD2s in the HRP we didn't have source materials for (because re-exporting from source is always superior as MD2 has pretty destructive compression, not unlike JPEG).

[Jimmy]

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

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.

I don't think you quite got what I was saying. I was rather saying that even though voxels are old technology in his eyes, that they were in fact ahead of their time because that's probably what the future of gaming will come down to. It really seems to me that mostly only people before the age of the source code get a lot of stuff like the clamoring for voxels. But whatever, I find Plagman's point of view much clearer in this case, but I hope that sooner than he thinks they can be implemented proper, or at least someone can come up with a good KVX-MD3 converter.

[Hendricks266]

Plagman, on 20 September 2011 - 05:05 PM, said:

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.

Please elaborate on what the preprocessing does; I forgot to ask you that before. As long as the results can be opened by other programs (in other words, so the output files as distributed in the HRP won't be orphaned) then I think that's a great idea.

Plagman, on 20 September 2011 - 05:05 PM, said:

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

I understand it, that doesn't mean I agree with it. I understand that you are worried about the three factors I pointed out in my post:
1. source code bloat
2. waste of CPU time/cycles/electricity for having to re-convert the voxels every playtime
3. unoptimized resulting models
I agree that these factors need to be mitigated for an effect implementation. However, I disagree that their existence should preemptively stop any work on overcoming them. It's my time, I'll waste it as I choose. In any case, a kvx2md3 would be a good thing to have.
(#2 could be solved by implementing a "model cache" if you will, but that has its own disadvantages.)

Plagman, on 20 September 2011 - 05:05 PM, said:

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.

I didn't know any of that, but I'm glad you explained that in a public place. I think the main concern was the loss of bones so modifications are difficult without the source, and sources are lost all the time and withheld too for good reasons.

[Plagman]

Hendricks266, on 20 September 2011 - 06:14 PM, said:

Please elaborate on what the preprocessing does; I forgot to ask you that before. As long as the results can be opened by other programs (in other words, so the output files as distributed in the HRP won't be orphaned) then I think that's a great idea.

The preprocessing does a few differents things:

• It calculates the bounding box information for the models; this is part of the MD3 spec, but none of the exporters actually seemed to correctly fill these members. I assume Quake 3 didn't actually use them, hence the disregard.
  
• It repacks all the geometry from the formats used in MD3 to raw data that can directly and efficiently be fed to a GPU
  
• It calculates the TBN basis for every triangle, which is needed to use tangent-space normal maps

I would probably want this information to be dumped in a companion file to the MD3 model, such that the MD3 file by itself can still be used as-is by other things.

Hendricks266, on 20 September 2011 - 06:14 PM, said:

I understand it, that doesn't mean I agree with it. I understand that you are worried about the three factors I pointed out in my post:
1. source code bloat
2. waste of CPU time/cycles/electricity for having to re-convert the voxels every playtime
3. unoptimized resulting models
I agree that these factors need to be mitigated for an effect implementation. However, I disagree that their existence should preemptively stop any work on overcoming them. It's my time, I'll waste it as I choose. In any case, a kvx2md3 would be a good thing to have.
(#2 could be solved by implementing a "model cache" if you will, but that has its own disadvantages.)

You know what they say: freedom with your own code stops where the freedom of the other dude's code begins. A model cache would essentially be the exact same thing as an offline converter too, just lumped in there for no good reason. I really think a good and efficient suite of tools is the way to go here.

About 3), most of what I was talking about on IRC regarding potential for optimization was based off the assumption that the Polymost code wasn't repacking voxel colors to a texture. I re-read it a few days ago and it does, which means that doesn't really apply anymore. Using the same logic verbatim should pretty much do what we want on the first try.

[Jblade]

MD2s are/were converted at run time to MD3? Or something like that? I guess that explains the terrible start up times I had with IW. I'm assuming converting all of my models to MD3 would then help speed up start times?

[Tea Monster]

Captain Awesome, on 20 September 2011 - 06:00 PM, said:

I don't think you quite got what I was saying. I was rather saying that even though voxels are old technology in his eyes, that they were in fact ahead of their time because that's probably what the future of gaming will come down to.

The future of gaming may use point-cloud technology, but lets be honest about this and admit that you only want to see colored lights on those 64x64(x64) pixel voxels. Saying that the sort of voxels that you want are the future of gaming is like saying that a couple of cavemen with clubs in a dugout canoe is a guided missile cruiser. Polymer should be used for what it was intended so that EDuke32 and Duke Mods in general can move FORWARDS, not backwards. Spending a shed-load of time making a 20 year old game look like a 20 year old game is a waste of time.

[Plagman]

James, on 21 September 2011 - 12:41 AM, said:

MD2s are/were converted at run time to MD3? Or something like that? I guess that explains the terrible start up times I had with IW. I'm assuming converting all of my models to MD3 would then help speed up start times?

They are, yes. That might explain some of it; were you using Polymer at any point? You'd also get the pre-processing pass which is known to take a pretty long time as well. If you have tons of high-res assets and models the startup times generally won't be stellar as all the DEFs are parsed at startup.

[Jblade]

Plagman, on 21 September 2011 - 09:40 AM, said:

They are, yes. That might explain some of it; were you using Polymer at any point? You'd also get the pre-processing pass which is known to take a pretty long time as well. If you have tons of high-res assets and models the startup times generally won't be stellar as all the DEFs are parsed at startup.

I wasn't using polymer but I did notice that startup times increased greatly with 'newer' snapshots (This was last year I'm talking about though, I haven't tried IW with a new version in a long time since it's finished and all)

[Plagman]

"Newer" snapshots had the polymer-preprocessing enabled unconditionally, so that's probably what you were seeing. Helixhorned changed it so it would only perform that pre-processing the first time you enable Polymer with rev 1750. Can you check that any snapshot that's newer than that mitigates your long startup issues?

[Jimmy]

Tea Monster, on 21 September 2011 - 05:52 AM, said:

The future of gaming may use point-cloud technology, but lets be honest about this and admit that you only want to see colored lights on those 64x64(x64) pixel voxels. Saying that the sort of voxels that you want are the future of gaming is like saying that a couple of cavemen with clubs in a dugout canoe is a guided missile cruiser. Polymer should be used for what it was intended so that EDuke32 and Duke Mods in general can move FORWARDS, not backwards. Spending a shed-load of time making a 20 year old game look like a 20 year old game is a waste of time.

Voxels are a feature that have been requested since the beginning of time. Stop being a dumbass, just because you don't want a feature doesn't mean that someone else doesn't value it. You'd have a hell of a fun time trying this shit over in the Doom community.

[Hendricks266]

The new ebacktrace1.dll fails to build for me. http://pastebin.com/gyWyKuPi

[DavoX]

If I offended you in some way or didn't get what you were saying then I apologize Plagman, sorry!

[Tetsuo]

I appear to be having a problem with the savegame function with the lateset build for OS X posted by Helixhorned recently. The full screen is fixed however and the rendering works great for the most part although I did have some slowdown happen if I try to start a new game twice.

[Jblade]

Plagman, on 21 September 2011 - 12:19 PM, said:

"Newer" snapshots had the polymer-preprocessing enabled unconditionally, so that's probably what you were seeing. Helixhorned changed it so it would only perform that pre-processing the first time you enable Polymer with rev 1750. Can you check that any snapshot that's newer than that mitigates your long startup issues?

Just checked IW with a new snapshot and yeah it starts up much quicker than it ever did

But I've noticed that globalsound doesn't seem to work reliably. I use it for cutscene voiceovers and stuff in IW and AMC TC and half the time it doesn't play the sound at all. This bug's been around for some time but I always thought it was my laptop and not an eduke32 issue, but I swear I've seen other people report it as well.

[Helixhorned]

Hendricks266, on 21 September 2011 - 04:47 PM, said:

The new ebacktrace1.dll fails to build for me. http://pastebin.com/gyWyKuPi

Looks like your libbfd.a needs libintl_*printf symbols and can't find them at build time. I have no idea where they reside (did a quick search for them in every *.a file in my mingw install).

Tetsuo, on 21 September 2011 - 05:32 PM, said:

I appear to be having a problem with the savegame function with the lateset build for OS X posted by Helixhorned recently. The full screen is fixed however and the rendering works great for the most part although I did have some slowdown happen if I try to start a new game twice.

Maybe you're mixing up saves of 32 and 64-bit sessions? Just an idea, even if it's a bit far-fetched. What's happening precisely?

James, on 22 September 2011 - 01:01 AM, said:

Just checked IW with a new snapshot and yeah it starts up much quicker than it ever did

But I've noticed that globalsound doesn't seem to work reliably. I use it for cutscene voiceovers and stuff in IW and AMC TC and half the time it doesn't play the sound at all. This bug's been around for some time but I always thought it was my laptop and not an eduke32 issue, but I swear I've seen other people report it as well.

I noticed these sound dropouts too, especially with custom mods. If you're getting this reliably (and reasonably quickly), you could do us a huge favor by attempting to bisect the bug. Just start with some old version X, if that doesn't show the bug, look at version round((newest-X)/2), and so on...

[Jimmy]

I've had the same issue with the regular sound command.

[Tetsuo]

Helixhorned, on 22 September 2011 - 09:22 AM, said:

Maybe you're mixing up saves of 32 and 64-bit sessions? Just an idea, even if it's a bit far-fetched. What's happening precisely?

No well firstly I never loaded an old save but I did notice it hasn't been showing saves properly at all no thumbnails and incorrect level names then I try saving over it and it didn't save. So then I tried removing the old saves to see if it just doesn't like saving over them and saving and it still doesn't work it forgets the savegames the next time I launch it and wont load any.

[Hendricks266]

Helixhorned, on 22 September 2011 - 09:22 AM, said:

Looks like your libbfd.a needs libintl_*printf symbols and can't find them at build time. I have no idea where they reside (did a quick search for them in every *.a file in my mingw install).

I added "-lintl" to the Makefile entry for ebacktrace1.dll and it compiled after that, but the string "libintl-8.dll" appears in the output leading me to believe it has an unwanted dependency.

[Helixhorned]

Tetsuo, on 22 September 2011 - 10:11 AM, said:

No well firstly I never loaded an old save but I did notice it hasn't been showing saves properly at all no thumbnails and incorrect level names then I try saving over it and it didn't save. So then I tried removing the old saves to see if it just doesn't like saving over them and saving and it still doesn't work it forgets the savegames the next time I launch it and wont load any.

This is very strange and I can't reproduce it with vanilla Duke savegames. Are you using a mod? I could have a look at the produced savegames if you sent them over.

Speaking of OSX, does anyone else get 'FBO initialization failed' messages? (And subsequently, shadows not rendering.)
Plagman: glCheckFramebufferStatusEXT returns GL_FRAMEBUFFER_INCOMPLETE_READ_BUFFER_EXT for me.