[Tea Monster]

I'm not a coder, but remember that any new features are bolted onto the code for an old 2.5D shooter. I know that walls and floors are completely seperate entities and are treated as such by the original code. Its only 'real' 3D games that have actual walls and floors!

Duke has Polymost and Polymer to make 'real' 3D but its creating the geometry from information used to create 2D levels, so you are going to get some strangeness.

[Jimmy]

I think the point of not releasing Polymer was because the team already knew about most of this.

[Parkar]

zchri9, on Jun 27 2009, 01:01 AM, said:

Are there any plans to optimize Polymer a bit?
Using Polymer and DukePlus together on one of the DukePlus maps (called Called to Action?) I get less FPS in some parts of the map then I get in Crysis.
In some parts of the map I was getting a FPS as low as 20FPS while in Crysis even on the most graphical levels (the ice levels) I get around 30 - 40 FPS Maxed out 1440 x 900 with no AA

You have to remeber that Crysis is built from the ground up to do what it does while Polymer is built ontop of an engine where no thought was put into supporting what polymer does.

Unless stuff has changed since I tried Polymer last the CPU is the botle neck on a modern PC at the moment due to the pre caclulations thats done before rendering.

DanM, on Jun 27 2009, 01:39 AM, said:

i think optimization will be the last thing on the list
once it all sits right they they will probably begin getting it optimized

the way light hits surfaces in places is a bit funny
point lights really light up walls in places but neglect the floors and ceilings alot as an example

spotlights that change through level changes like a door opening can also sometimes affect a point lights brightness in other rooms aswell.

Thats due to the max ligths per surface being to low to show all lights hitting the floors. With a powefull enough machine you should be able to upp that limit. I think I have mine set around 12 or 16 while default is 5 I think. Note that this will affect framerate though.

[Stabs]

for the moment optimization for me is splitting large sectors that may share multiple point lights, like roads and long hallways

usually try to keep a halfway sector in between lights with no light SE's in it, seems to work better for larger lights distributing the light properly.

come on flashing SE51 i want you so bad heh

making the light textures work as breakable light sprites that turn into flashing light would be a feature most awsome, imagine the absolutley insane crazy light breaking, glass smashing action scenes you could create with that, combine that with a nice polymer texture marble foyer with the new RoR and oh yes it might not be DNF but its close enough.

props to Plagman & TerminX for this stuff, its just totally of the scale.

edit : whats that console command parker?

[zchri9]

Parkar, on Jun 27 2009, 01:59 AM, said:

You have to remeber that Crysis is built from the ground up to do what it does while Polymer is built ontop of an engine where no thought was put into supporting what polymer does.

Unless stuff has changed since I tried Polymer last the CPU is the botle neck on a modern PC at the moment due to the pre caclulations thats done before rendering.



Thats due to the max ligths per surface being to low to show all lights hitting the floors. With a powefull enough machine you should be able to upp that limit. I think I have mine set around 12 or 16 while default is 5 I think. Note that this will affect framerate though.

Polymer runs fine.
It was just the called to action map that lagged like hell.
With E1, E2, E3, E4 the frame rate is fine. I was just playing through called to action map thinking 'Oh god, this is unoptimized'

[Stabs]

zchri9, on Jun 27 2009, 03:08 AM, said:

Polymer runs fine.
It was just the called to action map that lagged like hell.
With E1, E2, E3, E4 the frame rate is fine. I was just playing through called to action map thinking 'Oh god, this is unoptimized'

thats probably my map, iam yet to convert that over to work fine with polymer, its probably the
fact its massive e1 e2 e3 e4 are all about 3 - 400 hundread secotrs i think, that map is around 1600 and there is alot of dynamic fire sprites.

might have to use a hub system to split it on the subway, so the destroyed city is on its own map.

[zchri9]

This just came up as a random thought.

What if the water from the fire hydrant formed a puddle? With Polymer the water would look very good and be reflective.
Sure the hydrant forming a puddle would be a completely useless feature but it would make Duke 3D appear more modern.
The only problem I can think of with this idea is that a timer would have to be put in so the whole map doesnt flood with water and from my guess a timer would probably involve con editing.

[Stabs]

zchri9, on Jun 27 2009, 02:49 AM, said:

This just came up as a random thought.

What if the water from the fire hydrant formed a puddle? With Polymer the water would look very good and be reflective.
Sure the hydrant forming a puddle would be a completely useless feature but it would make Duke 3D appear more modern.
The only problem I can think of with this idea is that a timer would have to be put in so the whole map doesnt flood with water and from my guess a timer would probably involve con editing.

could just make hydrants spawn a translucent blue blood puddle like on bodys and make it grow like them, sounds like it should be more of a dukeplus feature than a polymer one.

[zchri9]

DanM, on Jun 27 2009, 03:53 AM, said:

could just make hydrants spawn a translucent blue blood puddle like on bodys and make it grow like them, sounds like it should be more of a dukeplus feature than a polymer one.

Yeah, Probably should be a DukePlus feature. Would still be a nice feature in EDuke32 though. Awesome reflective water puddles.

After all awesome reflective water puddles are the way of the future.

[Chip]

2 questions (not really aimed at polymer but its Eduke32 related)


1. Will there ever be support for model sticking or what ever its called (allowing 2 models to attach to each other) someone said that MD3's support this feature but its not implimented into Eduke32. I would like to know if its something that may be thought about in the future or if it will just be ruled off as there's not enough dmand for it at the moment? (Since I'm probably the only person who wants it )

2. Will the "move" commands ever be able to support game-vars for their number so we can have an easy changeble movement number without needing to define like 200 odd move commands for different varying speeds?

[Danukem]

DanM, on Jun 27 2009, 03:07 AM, said:

come on flashing SE51 i want you so bad heh

But where on the sprite is the information defining the flashing going to go? Pretty much everything is already taken (hitag, lotag, xvel, yvel, zvel, extra, shade). I guess the only thing left is pal. Maybe pal 1 could be random flashing, and the other pals (2-255) could be for different cycler rates? Or there could be 8 pals set aside for different kinds of random flashing, and the rest for cyclers.

I could add that effect with CON right now, but I suspect that TerminX will be adding something like that, which would be better.

[Tea Monster]

Chip, on Jun 27 2009, 05:28 AM, said:

1. Will there ever be support for model sticking or what ever its called (allowing 2 models to attach to each other) someone said that MD3's support this feature but its not implimented into Eduke32. I would like to know if its something that may be thought about in the future or if it will just be ruled off as there's not enough dmand for it at the moment? (Since I'm probably the only person who wants it )

That would be cool. + 1 on this.

You'd have to break the model into sections with the arms being separate entities so that the hands can stick to the gun and the 'shoulders' can pivot to allow this. I actually tried making the current player model support holding different weapons and its pretty much pointless unless you try to implement something like this. You'd need to cycle all the different animations with the model in the position for each weapon, which is a pain in the ass, and kinda silly really.

The other problem with that is that nobody said that they wanted to do the coding part of this so it kind of went nowhere.

I don't know how its done in modern games, but it may be that with modern 'skeletonized' mesh formats such as (plug plug plug) MD5, the attach points are in the wrist or hand bones and you don't need to detach anything as the skeleton will have some kind of IK system that will just move the other bones of the arm so it works without looking like hes dislocated his shoulders.

[Plagman]

Polymer will support model attachments to MD3 tags through CON code; it's been planned for a while.
Also, tying polymer dynamic lights to flickering lights and/or light switches has been possible for a while. Lighthacks had maxshade/minshade members to tie the intensity of the light to a range of shades on the sector it belonged to. This allowed Parkar's E1L1 lighthacks to function properly with flickery polymer lights and lightswitches. However, I forgot to reimplement it when overhauling the light management code in polymer a while ago, so it doesn't work as of right now; it's easy to put back in, though.

[Fox]

Wow! I tested it, quite (very) impressive.

1 - Does the shading on wall borders are present only if there are light sources in the current map? I would like to see it always present on every wall, much like Duke for Saturn.

2 - The hard-coded light effects are only temporary, and eventually will be set through DEFs, right?

[HellFire]

Plagman, on Jun 27 2009, 07:26 PM, said:

Polymer will support model attachments to MD3 tags through CON code; it's been planned for a while

Shouldnt it be via DEF ?

[Plagman]

No. DEF would just be for boring stuff like filenames and model frame ranges. Setting animations and attachments through CON would allow to bypass every limitation from the current definition system.

[Stabs]

dynamic or pal,, whatever works best

is there a chance sprite 440 can be made dynamic like fires this would help heaps wih what iam doing at the moment

[TerminX]

440 is blank, so... nope!

[Stabs]

oopps , soz dunno how i messed that up i meant 1034

[Chip]

Quote

Polymer will support model attachments to MD3 tags through CON code; it's been planned for a while.

Thats fantastic!
I really can't think of anything else I want from the game now.

[Stabs]

just tried 1447

fires wont cast dynamic light, but fires spawned from a rocket explosion will
light from enemey gunfire stays on in the level for about half a minute before going
dukeplus spawner effect ceases to work

so some things are broken or they are getting overhauled, but it did seem to run a bit nicer

do i have to tag certain sprites now for dynamic lights cause that would be great and far from broken heh

[gt1750]

Looks like r1447 doesn't want to work with DukePlus when Polymer is on. I get the same enemy fire light bug as DanM and when I approached the end of E1L1, the game crashed saying "Too many sprites spawned".

Without DukePlus, it works pretty much like the previous versions - performance level is just about the same, I get some tesselation errors reported and the game ocassinoally crashes.

[Stabs]

hmm appears to be dukeplus related problem & since 1443 mapster crashed if you loaded any other map other than newboard and went into 3dmode, & in 1447 that still happens also when you place any addidtional lights into the map they wont work, probably suggest 1440 atm.

[Danukem]

I don't have the latest build and I have no idea what is going on. Probably what I'll do is disable all of the Duke Plus code that does anything with dynamic lights until Polymer is actually released. It's too much trouble to have to keep changing it to correspond with the latest unreleased Polymer build.

EDIT: Here is the latest DP code.

http://deeperthought...m/dp/dpcons.rar

[MusicallyInspired]

The latest build fixes my sprite and snail-crawling FPS issues! Hooray!!

[Plagman]

Polymer should work more or less properly with Radeon X1x00 cards now. There still are issues with big shadows, so disable shadows if you get overly dark flickery walls and floors.
I had to defile myself by buying a Radeon X1800 and fight against their buggy driver for a full day to figure out what their problem was, so be grateful!

[SwissCm]

Plagman, on Jun 30 2009, 04:18 AM, said:

Polymer should work more or less properly with Radeon X1x00 cards now. There still are issues with big shadows, so disable shadows if you get overly dark flickery walls and floors.
I had to defile myself by buying a Radeon X1800 and fight against their buggy driver for a full day to figure out what their problem was, so be grateful!

Suck it up motherfucker :o

[Master Fibbles]

Plagman, on Jun 29 2009, 02:18 PM, said:

I had to defile myself by buying a Radeon X1800 and fight against their buggy driver for a full day to figure out what their problem was, so be grateful!

Now that is dedication.

Of course, if I had an ATI card I'd be grateful. I'm just saying that that is dedication.

[Jimmy]

I've got a request about Polymer. Is there anyway you could let the Polymer engine run on PC's without Shader 2.0? Have it work similarly to OpenAL and OGGs, if you try to play an OGG and you don't have OpenAL installed, it just ignores it. I know the lights won't work, but the other features which apparently won't be ported to Polymost or the Classic Renderer would be a godsend. If this is already in the works, just ignore it. But I noticed when I try to run Polymer it just crashes(I don't have shader 1.0 even.)

[TerminX]

No, that is not possible. Polymer absolutely requires hardware made in the last 5-6 years.