Personal tools

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Sandro

Pages: 1 ... 14 15 [16]
Mapping / Re: materialsystem: terrain
« on: March 13, 2011, 03:53:48 pm »
Hello. Is it possible to make reverse terrain?

It is nice feature, but sometimes the better way to terrain in revers order (if Z less than floor, use stage texture). 

Could be done, either by a new stage type, or by allowing ceil<floor for the terrain stage.

For example, if we have one middle texture and want to blent it on top and bottom of the texture,

Do you aware of tape stage? Looks like it does what you want, but in reverse order.

PS: Each stage is a new rendering pass, so it slows the game.

First, just to clarify things: cuts are not always grid aligned by new method. This is the artifact of a chosen cutter brush (cube, as it seems).

Of course, this problem exists. Brush subtraction could result in much simpler shapes, and could snap the split planes to exising edges. But this new algorithm can't do that: it designed so all split planes intersect at a single point (shared apex of all pyramids victim brush being cut into). So, the only variation possible with this algo is to move apex point to the position where most splits will pass through the existing edges (or vertices at least).

Mattn, improving the algorithm to what you are asking for will require a major rewrite, changing it's nature. Definitely possible, but will require about 10x of work compared to the current version. I think, it will be better if my project newbie enthusiasm ;D will be directed to the renderer -- which definitely requires a lot of improvement to meet modern standards. Not to mention the bugfixes.
After all, the renderer is what player sees -- not the Radiant.

On the other hand, it is possible to reintroduce old behaviour as a configuration choice. Looks like it does pretty axis-aligned cuts with boxes, and that could be useful. Just fix the code to avoid insane geometry -- original subtract tool was able to create something really bizarre, like 17-faced cube (of which, 9 faces are invisible, and 3 faces are coincident). No wonder ufo2map had problems handling map made with CSG subtract.

Even more, it is possible to do the hybrid tool, which retains the old behaviour for axis-aligned faces, but uses pyramid cutter for all other. Could be a 3rd configuration choice.

These two are very simple'n'easy, and I'm willing to do them if someone makes the configuration and UI code. In case they are requested, of course :)

Finally done something that could be released. New CSG subtract is in the master as 36011dc324793d8b64cd5d4d72c28c2c45de39b8
Not all problems fixed, but I managed to compile and play map having a box brush which was cut 15 times with a 10-sided sphere buried to the different depths, a feat almost impossible with previous version. And map had all its geometry correct in game.
Geometry is still broken sometimes when doing a multiple overlapped cuts, but fixing that will require major changes to the Radiant computational geometry engine (as much as I understand it), so -- nothing on that, sorry.

Mattn, Radiant code base is much bigger than I beleived it to be, and is very different from the game one. Looks like trying to work on both of them will be biting much more than I can chew. Means -- no more Radiant patches from me. :(
Will work on the game only.

Artwork / Re: Artwork needed
« on: February 25, 2011, 07:15:28 pm »
p0ss, are you sure about the alpha channel being the reason for file size increase? Most likely, the reason is jpeg->png conversion. Remember, png is the lossless format, so it takes more space than jpeg.

BTW, which png optimizer you are using? A quck run of pngout over the you just posted saved about 330 kilobytes. Not much, but that's still an improvement. Maybe you will try this program?

And thanks a lot for providing the normalmaps!

Discussion / Re: refresh rate and maps
« on: February 25, 2011, 02:16:40 pm »
I suppose you are using CRT display? There is no need to increase refresh rate for the LCDs.

If you are using ATI, you can override default frequency in Catalyst Control Center. Nvidia's driver also has the override function IIRC. Or you can use 3rd party tool like RIVATuner/ATI Tray Tools.

Looks like some explanations are needed :)
I'm working on project as programmer, not a mapper. Those maps are just rendering engine tests, nothing more. And I've never used Radiant before :)

So, for me it's just a piece of math that could be done better.


On the second thought, I should have posted to the mapping forum! In fact, what I want to know is: do mappers want that change, to be able to create concave objects in quick and and more safe way, or that's not needed?

I'm not sure if it should be discussed here or in the "mapping" forum, but "coding" looks more likely. So, here goes:

Today I have tried to create playground for testing transparencies (there are not much of them in game), and immediately stumbled upon a problem with CSG subtract. Cutting holes with simple (box) brushes results in more or less editable geometry, but that's not true for more complex shapes.
For example, cutting a box with cone results in multiple narrow, odd-shaped "splinter" brushes, some with a very low volume. Such geometry is very hard (sometimes outright impossible) to edit, and ufo2map doesn't like it very much, complaining about microbrushes. I've even got wrong ufo2map output (polygons where they should not be) in a relatively simple case.

All of that happens because Radiant takes the simples approach possible -- it just (recursively) cuts brush A with all planes of brush B, slicing out wedge-shaped brushes with all cuts but first and last.
That's not the only method possible: brush A could be cut some other way, generating more editable and generally safe geometry. One of them, which I like the most, is to cut brush A into pyramids based on the brush B sides. For a 2D example, look at the attached drawing.


Discussion / Re: Funny screenshots!
« on: February 23, 2011, 03:17:24 pm »
Taman trying to take a better tactical position. :D Happened to me in skirmish game yesterday.

Just a typo in 418182c172cfd -- mising minus sign for x coordinate of first point in vec3_t points[]

Looks like the same bug: (and it was mentioned at even more topics on the forum, can't remember where).
Reason is the z-fighing due to polygon offset applied to the incorrect rendering mode (should be FILL, no LINES). Here's the patch:

Bugs prior to release 2.4 / Re: [FIXED] Still having some glowmap issues...
« on: February 15, 2011, 11:02:13 pm »
MCR, thanks! :)

Mattn, yes, there were few state leaks remaining. Hopefully, attached patch will plug all of those  ;) At least, I traced everything that is called from R_RenderFrame(), so it's supposed to be complete.
Still, glowing cursor box was niiice :) Maybe, reintroduce it as a feature? That's just a few lines of code.

Bugs prior to release 2.4 / Re: Still having some glowmap issues...
« on: February 14, 2011, 04:22:15 pm »
Oops! I didn't notice that shaders were switched off when lighting is disabled, and few other things. Now glowmaps are working for me, but patch is not as clean as I hoped.

Here it is:

Bugs prior to release 2.4 / Re: Still having some glowmap issues...
« on: February 13, 2011, 06:27:38 pm »
+city medium

Bugs prior to release 2.4 / Re: Still having some glowmap issues...
« on: February 13, 2011, 06:15:36 pm »
Ok, I will work on fixing those issues. BTW, there is some other problem introduced -- some staged materials started to glow. I'll fix that too, so please delay applying this patch to master.

Bugs prior to release 2.4 / Re: Still having some glowmap issues...
« on: February 13, 2011, 05:38:27 pm »
Culprit found. Writing to the glow buffer was disabled for the textures without glow map, making glow depend on drawing order.
Here's the patch against current master:

Pages: 1 ... 14 15 [16]