[Micky C]

As Plagman would say, it's easier to make it and have it work as opposed to have it work efficiently.

[Kyanos]

Mark., on 27 March 2014 - 03:28 PM, said:

I can't imagine the trouble of having to map in triangles to closely match the renderer.. I know the detail of my previous pics is hard to see, but how the renderer determines those extra polys is beyond me. If I was building a model I wouldn't have made it that way. But I'm sure there is a very technical reason that I couldn't begin to understand.

I had to compare the two. Blender has an automatic face triangulation feature too, I used it in the md3 export script, both make 6 faces for an octagon, but in different ways.

About my earlier comment, if you made all your sectors out of triangles I think Polymer would not change anything than to triangulate wall faces. It's odd shaped sectors with many points that end up as many faced polygons. By no means am I referring to anything I saw in your pics, it just a generalization by me.

[Mark]

I suppose the renderer is doing something like the "simplify mesh" command in my modelling program. This is an end view of a cylinder before and after the command. It shaves a few faces off the model while retaining its original look.

Attached thumbnail(s)

• 

[Stabs]

yes i highly recommend you square of circular edges on sectors lest it make a fuckton of very long triangles. unused points that serve no purpose make further triangles and unnecessary rendering

btw plagman i thought wireframe showed you exactly whats being rendered in normal mode, so its only rendering the whole map cause of wireframe, because you can stand in one spot and it dosnt display the whole level, rotate to left or right a little bit and the whole level can just show up

[Gambini]

Mark., on 27 March 2014 - 05:05 PM, said:

I suppose the renderer is doing something like the "simplify mesh" command in my modelling program. This is an end view of a cylinder before and after the command. It shaves a few faces off the model while retaining its original look.

It doesn´t retain its original look. What you have there is a ONE POLYGON less cyllinder that will surely look horrible ingame. When polygons become so long and thin like in your 2nd image, smoothing (and possibly lighting, depending on the engine) will show ugly polygons interpolation. I, by practice, cut the polygons manually on my models before triangulating.

[Stabs]

Gambini, on 27 March 2014 - 09:06 PM, said:

It doesn´t retain its original look. What you have there is a ONE POLYGON less cyllinder that will surely look horrible ingame. When polygons become so long and thin like in your 2nd image, smoothing (and possibly lighting, depending on the engine) will show ugly polygons interpolation. I, by practice, cut the polygons manually on my models before triangulating.

pretty much, vectors are the future they have none of those constraints, we only just now have large scale vector engines like minecraft

come on carmack make that super vector ray trace engine already

[Mark]

Gambini, on 27 March 2014 - 09:06 PM, said:

It doesn´t retain its original look. What you have there is a ONE POLYGON less cyllinder that will surely look horrible ingame. When polygons become so long and thin like in your 2nd image, smoothing (and possibly lighting, depending on the engine) will show ugly polygons interpolation. I, by practice, cut the polygons manually on my models before triangulating.

I don't have much of a choice with the program I use. It creates ONLY in triangles. I'll have to take a closer look at a bunch of my models. I haven't noticed the interpolation you mentioned. The first time I used the "simplify mesh" command and saw the wireframe results I also thought it would screw up the looks. Maybe the way the program wraps the skin around the object takes it into account. BTW, that command saved 4 faces not 1. Here is an example of a model I made for the HRP using the poly reducing method which reduced by 80 faces. It looked fine to me from all angles.But enough of this. I'm getting off topic.

Attached thumbnail(s)

• 

[Fox]

I got a small problem with tilefromtexture... yoff -1 is not working, instead the value is set to zero.

[Helixhorned]

Mark., on 27 March 2014 - 12:41 PM, said:

I just tried out the wireframe mode. Looks cool. What I immediately noticed was that when the map is converted to "model" form in the game that many extra walls are created that were not put in through mapster. I'm not referring to the diagonal line added to a square or rectangle, like in a modelling program, but extra walls extending out from a corner to other sectors for example. I wonder how many more polys are added in the whole map. A lot !!

Polymer uses the gluTess* functions to tesselate ceilings/floors simply because it needs triangles futher down in the pipeline. As for the count... a polygon with N >= 3 vertices tesselates to N-2 triangles, so you could say that the number of triangles is roughly proportional in the number of walls. Nothing to worry about.

Drek, on 27 March 2014 - 03:16 PM, said:

I bet many maps could be optimized to take the guess work out of polymer`s triangulation. I bet every poly needs to be 3 sided, with 3 verts. Extra points make extra tri`s.

I don't think that the tesselation is a bottleneck.

[Helixhorned]

Fox, on 29 March 2014 - 11:59 AM, said:

I got a small problem with tilefromtexture... yoff -1 is not working, instead the value is set to zero.

Should be fixed with r4402, tough I didn't test it.

[Plagman]

The only problem with the current tessellation approach is that with forward rendering, triangles are rendered once per light that affects them. Sectors can create triangles with extremely large areas, which will end up rendered fully for every small light that touches them. That is why breaking down big sectors in smaller sectors is sometimes a performance win, as fill rate can become an issue. One optimization that would help with the current scheme would be to project the light volume onto the screen before doing a light pass, and set a scissor rectangle to the boundaries of that area before rendering the affected geometry. The real fix would be to move to a deferred approach.

[Fox]

Helixhorned, on 29 March 2014 - 02:12 PM, said:

Should be fixed with r4402, tough I didn't test it.

It's working now, thanks.

[Hendricks266]

Helixhorned, on 29 March 2014 - 02:12 PM, said:

Should be fixed with r4402, tough I didn't test it.

Oh, fuck. Somehow I thought that ~0 would be INT32_MAX when it's really -1. That trick only works with unsigned numbers (UINT32_MAX).

[Helixhorned]

Plagman, on 29 March 2014 - 02:44 PM, said:

Sectors can create triangles with extremely large areas, which will end up rendered fully for every small light that touches them. That is why breaking down big sectors in smaller sectors is sometimes a performance win, as fill rate can become an issue.

I stand corrected then. Thanks for the clear explanation!

[Micky C]

What about Parkade and CBP 8 which are also kinda slow even with lights disabled?

[Stabs]

something wrong with VIS again in 4402 with this new shading, still very bright and now does this in DNE07

in game 4402



mapster 4402



I noticed that firing your weapon now removes the fog, i could of sworn that got removed earlier

so shading mode 3, it needs pals on walls now for them to be effected by fog?

[Fox]

Sector filler should totally be used for rendering fog separately from pal, instead of blend which is defective in OpenGL and unavailable for masked walls.

Just saying.

[Helixhorned]

Stabs, on 29 March 2014 - 05:01 PM, said:

something wrong with VIS again in 4402 with this new shading, still very bright

I'll return to the brightness issue later.

Quote

and now does this in DNE07

in game 4402

eduke32 2014-03-30 11-56-17-35.png

mapster 4402

mapster32 2014-03-30 11-55-39-80.png

What exactly differs from previous versions there? The in-game one looks pretty bad, but I just tested out that map, and it looked OK. (Note: a few EDuke32 commits were made in between.)

It seems that you're using r_usenewshading 3 in-game, but 2 in the editor. Always make sure that you sync these variables, none of the apps will do that for you.

As for the effects you're seeing: as mentioned earlier, r_usenewshading 3 will never produce negative fog starting distances. This is the reason why the screen is tinted overall by the fog with mode 2, but starts untinted with mode 3.

Quote

I noticed that firing your weapon now removes the fog, i could of sworn that got removed earlier

No, that was never removed. That looks like another consequence of what I said above. With mode 2, if you have non-infinite visibility, there's some attenuation at distance 0 already, which is especially noticeable with colored fog.

Quote

so shading mode 3, it needs pals on walls now for them to be effected by fog?

No, fog should be taken over from a wall's sector. I couldn't reproduce a case where I would need to set a wall's pal to a fogpal separately, either. What makes you think so?

[Helixhorned]

Fox, on 29 March 2014 - 06:44 PM, said:

Sector filler should totally be used for rendering fog separately from pal, instead of blend which is defective in OpenGL and unavailable for masked walls.

Are you suggesting to use sector[].filler / blend (it's the same member!) for a different purpose in the GL modes than when in classic? I think that's a bad idea. It would necessiate writing code conditional on the current rendering mode when dealing with that member then, both internally as well as from CON. (Ideally, mods should be agnostic to the rendering mode.)

There is wall[].blend in Lunatic. It will simply be not available in the non-Lua builds because that would require extending the on-disk binary map format. That has nothing to do with sector[].blend, though.

[Helixhorned]

Stabs, on 29 March 2014 - 05:01 PM, said:

and now does this in DNE07

Just to be clear: if an "old" mode, such as in this case r_usenewshading 0, 1 or 2, starts behaving differently with new revisions, it's a bug. Therefore, it's important to be explicit about whether old functionality was broken or that you're just not content with the new developments.

[Fox]

Helixhorned, on 30 March 2014 - 01:34 PM, said:

Are you suggesting to use sector[].filler / blend (it's the same member!) for a different purpose in the GL modes than when in classic? I think that's a bad idea. It would necessiate writing code conditional on the current rendering mode when dealing with that member then, both internally as well as from CON. (Ideally, mods should be agnostic to the rendering mode.)

There is wall[].blend in Lunatic. It will simply be not available in the non-Lua builds because that would require extending the on-disk binary map format. That has nothing to do with sector[].blend, though.

No, I am saying that .filler shouldn't have been used for custom blending tables in the first place. It makes no distinction beetween floor and ceiling and it's not avaiable for walls in the original map format, so it's an incomplete feature. Besides it's a feature that doesn't extend to OpenGL modes, so I don't think it's a feature that should be acessible in the map editor (with old map format).

Sector .filler should be used for displaying fog independent of pals, and sprite .filler should be reserved. Instead .alpha should be extended for floors, ceilings and walls; and blending tables would be acessible by shifting left by 8. And you could add a bitfield of additive or substractive colors in OpenGL mode starting with 2^16.

[Stabs]

Helixhorned, on 30 March 2014 - 02:12 PM, said:

Just to be clear: if an "old" mode, such as in this case r_usenewshading 0, 1 or 2, starts behaving differently with new revisions, it's a bug. Therefore, it's important to be explicit about whether old functionality was broken or that you're just not content with the new developments.

I've sorted it all out now, DNE all works around new shade 3 now

[Mark]

Would you mind giving us a hint on what solved your issues?

[Stabs]

wrote a custom script for that level, uses very a very different vis from other versions, 2 was rather lax with where you could put fogging in and make it looked like the whole room was done right, rather strange how they worked before.

also if your using dukeplus as a base for any mods a spotlight in conjunction with a se150 can cause it to be seen as -1 which is pretty much infinite, its why my doors in DNE01 lagged when opening and DNE01 was running so terrible, but don't go removing all your 150's just yet, should have a fix for that one in con or eduke form (not sure) soonish.

[Helixhorned]

Fox, on 30 March 2014 - 02:34 PM, said:

No, I am saying that .filler shouldn't have been used for custom blending tables in the first place. It makes no distinction beetween floor and ceiling and it's not avaiable for walls in the original map format, so it's an incomplete feature.

Ah, I suck! We don't use sector[].filler at all, it's sprite[].filler that was taken for the new functionality. Sector filler has exactly the problems you mention -- we'd need two members for the ceiling and floor, but we have only one.

Quote

Besides it's a feature that doesn't extend to OpenGL modes, so I don't think it's a feature that should be acessible in the map editor (with old map format).

Well, other features can be specific to one rendering mode, too. It's the mapper's responsibility to make sure that either the map looks as intended anywhere, or state which renderers are suitable in the mapping template.

Quote

Sector .filler should be used for displaying fog independent of pals (...).

Yeah, might be doable... one needs to research a bit whether this member has any use internally, in which case it could be moved somewhere else, or in existing CON code, which would be kind of a blocker for using it for a new purpose.

Quote

Instead .alpha should be extended for floors, ceilings and walls

Alpha isn't a member of the on-disk map structures, but rather of spriteext[], which is only there in the game.

[Plagman]

Well, sorta; spriteext partially lives on disk through .mhk files. These days I guess you could argue a build map file is both a .map and a .mhk.

[Fox]

Anyway, I don't think sprite blending should be extended to the map editor, but the functionality should be added to .alpha.

Edit: I just noticed a small detail, the sprites displayed on the screen when you are checking a security camera need widescreen orientation flags, no?

[Helixhorned]

Plagman, on 31 March 2014 - 01:53 PM, said:

Well, sorta; spriteext partially lives on disk through .mhk files. These days I guess you could argue a build map file is both a .map and a .mhk.

Right. Plus, it's an engine-side structure, so my comment about it existing in the game only was misleading.

Fox, on 31 March 2014 - 06:43 PM, said:

Anyway, I don't think sprite blending should be extended to the map editor, but the functionality should be added to .alpha.

Since sprite[].blend is part of the spritetype structure, it's obviously there in the editor, too. There are simply no "user-friendly" ways of accessing it, you have to use one of the scripting languages.

Quote

Edit: I just noticed a small detail, the sprites displayed on the screen when you are checking a security camera need widescreen orientation flags, no?

In 1680x1050, viewing through a security camera looks fine to me. Can you post a screenshot describing what looks off to you?

[Fox]

Spoiler

[TerminX]

You gave the cameras manual pan and zoom functionality?