¡Needs testing!

[safemode]

true, could put in nifty sliders for each catagory.

[chuck_starchaser]

Techniques...

Whoever commits a new (working) executable gets a prize of $100 today, going down to $90 tomorrow, and so on, $10 down per day; money order sent after proper documentation is added to the wiki

[ace123]

I can spend an hour to build one tomorrow in VC7 (or I might be able to finish up getting VC9 working -- all I need is python 2.4 libs).

What new feature has been committed lately that you need?
I don't think the techniques code has been put into trunk svn yet, has it? I suppose I could check out the branch, but I figure it isn't ready yet.

[chuck_starchaser]

Well, that's it; supposedly it needs testing, but I'm not even sure there's any testing actually happening. Features? Just to be able to specify special shaders in xmesh; I believe that's all I need. I'm just trying to expedite the only way I can think of...
$90

[safemode]

No reason why someone with a win32 build cant build klauss's branch directly. Shouldn't matter that it's not trunk.

It shouldn't be merged into trunk until it's ready though, and there's no reason why building a win32 bin necessitates that.

No need to make it a public bin or even a bin on the svn. Just link it here or put it up on the sourceforge site and remove it when "testing" is done.

[chuck_starchaser]

No reason why someone with a win32 build cant build klauss's branch directly. Shouldn't matter that it's not trunk.

It shouldn't be merged into trunk until it's ready though, and there's no reason why building a win32 bin necessitates that.

No need to make it a public bin or even a bin on the svn. Just link it here or put it up on the sourceforge site and remove it when "testing" is done.

Indeed; I should have clarified; my requirement is not for an official binary in trunk; --just something I can use to start working on the new shaders.

[safemode]

By the way, Chuck. The only thing i really miss from all the images you posted about the progress being made in the shader is the metal bodies of the ships, looking like metal. What i mean is, there are no rivets, no lines where pieces were joined, no real look that the ship is made of smaller parts. It looks like each component was molded from a perfect single piece of material. Nothing looks dirty, nothing looks used (maybe that would be the damage texture?). Are we lacking the "detail" texture for the models? No paint decals with some sort of name or designation or association.

Is that all to come given artist's creating the textures, or is that stuff not yet even possible? Or am i being retarded and not realizing that these images only show off the shader's use of material settings, and textures are being deliberately left out to illustrate them.

[chuck_starchaser]

Hahaha, no; I'm being retarded by forgetting to explain that the pictures are, in fact, material tests without texturing. The only ship I've actually textured, so far, is the Demon; and I'm kind of ashamed to show it because the materials on it are not right, and there are tons of dds-compression related artifacts ... but if you must see it, here it is:
PU's current Demon fighter retexturing relase announcement.

For a rough idea what the intended look was, here's my previous texturing of the Demon, prior to shaders and dds, but with pretty representative renders:
http://vegastrike.sourceforge.net/forum ... 8995#78995

Last but not least, these are pics of it with the old texturing, but using glsl shaders under testing in Render Monkey:





And perhaps I should have put more effort into finishing this texturing better, but there's two reasons why it's still crappy and incomplete: 1) The unwrap for the Demon was my first unwrap ever, and it has serious problems; needs to be redone; and 2) Why struggle so hard with the limitations of current shaders? Might as well improve the shaders first.

With the next generation shaders, the cause of those artifacts (pessimal use of the scant dds bits) will be gone, btw. (Reason being that, right now, ambient occlusion is modulating, or a part of, all of diffuse, specular and glow textures, off-line, but dds is pessimal at representing smooth gradients; and then shininess is computed by the shader based on an ad-hoc formula from specularity, which is a terrible thing to do. In the next gen shaders, ambient occlusion will come from glow's alpha channel (and dds treats the alpha channel better than it treats r+g+b together), and the modulations will be done in the shader at full precision; plus, shininess will come from spec's alpha channel, rather than be computed using a totally arbitrary, straightjacket formula.)

So, to summarize: I got nothing to show; and the reason is that producing stuff to show is a huge amount of work, which work might as well cater the next generation of shaders, so the whole art pipeline is basically sitting there waiting for new shaders and tangents, and the new shaders have to wait for techniques. That's why I'm offering my life-savings for a working binary

[safemode]

sounds good. should be interesting to see how things look with better material shading.

it would be cool to see a single model that all of the available features can be taken advantage of to illustrate to everyone the potential visual quality of the game. Maybe get some other artists motivated by seeing just what we're capable of rendering now.

[chuck_starchaser]

That's the plan
In fact, I have partially redone Vegastrike's mine; and was planning to redo some ship too, to try and inspire your artists to adopt better tools and methods.
http://vegastrike.sourceforge.net/forum ... 59&start=0
But that's, as everything else, bottled up waiting for better shaders and texture packings.

[klauss]

Everyone: I just committed z-buffered far draw queues. Now... to properly do this I should make use of an extension that clamps the z-buffer (rather than clipping it) but I just noticed the advantages of using it are... theoretical at best (I saw no glitch without it).

Again, technically speaking, without it meshes could disappear at boundary cases (too near or too far). Too near can be adjusted with clever "offsets". Too far needs the extension. If anyone actually sees the glitches let me know.

Chuck: if things go well, I'll try hard to get a win32 build during the weekend. And, BTW, if I get one such build before anyone else I will not accept any money - you've done enough for me already, and it wouldn't feel right if you paid for it. I'm doing this as a hobby... for free. In fact I would hope everyone would thing that way. Perhaps others think it's a joke... but I know better

Edit: Something else - the commit includes tangents. But I couldn't get them to the shaders! I really don't know why the F it doesn't work, the shaders should see the tangents in the 3rd multitex coord (ie: gl_MultiTexCoord2), tangents are being computed (wouldn't say "right" yet, but something is computed), but the shader gets zip - can't figure this out. If anyone can help out here I'd appreciate. Maybe the GF6 doesn't support 4-component texture coordinates?

[safemode]

any screenshots of planetary rings no longer borked? or does that require even more fixing?

[pyramid]

Slow the wilde horses...
I'll do the testing tonite and post some shots.

And.. I'm absolutely with klauss. Money just doesn't pay the fun of open life If I could compile on win I'd done it already. Sorry chuck, no luck here.

[safemode]

I'm only a few steps away from getting cmake to the level where everything we use in VS (as dependencies) is autodetected and correctly used to build files. I have a windows 2000 vmware setup that I suppose i can get a free VC++ setup on and work on troubleshooting the win32 build process. Though, i really dont see that happening until the end of the month.


cant wait to see how far queuing plays with rings and planets and the performance issues many of us have noticed when viewing planets and large bases.

[chuck_starchaser]

Chuck: if things go well, I'll try hard to get a win32 build during the weekend.

Excellent!

And, BTW, if I get one such build before anyone else I will not accept any money - you've done enough for me already, and it wouldn't feel right if you paid for it. I'm doing this as a hobby... for free. In fact I would hope everyone would thing that way. Perhaps others think it's a joke... but I know better

Hahaha, well, you know better in the sense that you know I'd fork the money without hesitation; but they know better in the sense that it IS a joke, anyways; because we're all in open source because we're all far above money motivations; and this would be true even if money was exchanged. Someone is in need of money to buy a stick of ram and so commits and claims the prize, I send the money, and yet we both know it's still a joke and laugh about it.
Open source has been likened to a revival of the gift-culture of native Americans, and the parallel has merit. Yet, in the middle of a gift culture, trade and negotiation can, and do, exist; but there's a healthy dose of humor to it.
The reason I offered money is symbolic: In English language and culture, money is associated with "seriousness". Expressions like "I mean business" or "put your money where your mouth is", and all that... So, just my way of saying "seriously, guys; let's make this thing happen; I'm REALLY serious".

Edit: Something else - the commit includes tangents. But I couldn't get them to the shaders! I really don't know why the F it doesn't work, the shaders should see the tangents in the 3rd multitex coord (ie: gl_MultiTexCoord2), tangents are being computed (wouldn't say "right" yet, but something is computed), but the shader gets zip - can't figure this out. If anyone can help out here I'd appreciate. Maybe the GF6 doesn't support 4-component texture coordinates?

Damn!
Stupid question, probably: Why "texture coordinate"? Why not a vector, like the vertex normal, or as vertex color?

EDIT:
Or, if for some reason it *has to be* passed as texture coords, perhaps two texture coords with two coordinates each could add to the four needed parameters?
What does Ogre do?

[pyramid]

Also presented is (TA-TA) the planet rings with proper z-buffering based on latest svn.





What speaks actually against merging the changes into the trunk already. The code is might be not perfect, but it's also not broken. It's perfectly fine to have development being done in the main trunk and has the advantage of not having to maintain two versions for testing and being able to also test the latest commitments together in one shot. I'd very much welcome the merge at this point in time already.

I am not doing any testing on unit texturing besides checking if they look ok with current textures and the new shaders/techniques.

[safemode]

A lot of work has to be done on klauss branch i thought still, since no syncs were made as the trunk was getting updates. So well before any thoughts of merging, all the changes since the branching have to be reviewed to make sure nothing gets lost.


edit: Am i the only one who thinks the glow haze atmo effect on the ocean planet just looks wrong. I know the effect that it's supposed to mimic, but it just doesn't look right, something is wrong with it. I'd even go as far as say it would look better without it altogether, like the gas giant.

[pyramid]

I've mentioned it in one of my earlier posts. It seems that the planet fog doesn't read the rgb values from the system file anymore and probably assumes all 1,1,1. Also the edges are slightly dotted, which I suppose can be corrected by using a specific planet shader.

The merge to trunk has to be done sooner or later. The more time you wait the more will need to be merged later. And it's not only double work with testing right now. It also means that klauss' branch will probably not compile on many win machines with the different compiler versions without adaptations. There were also data side changes that do not reflect in klauss branch, means you need either to rename extensions or merge the changed cone to klauss' branch in order to be able use the current data set (what i partly did). Also changes done by klauss in vs.config make load screens disappear. Overall many things are broken when trying to test gfxtchniques using current data set.

All of the code that klauss changed was not touched in trunk, so an easy copy of the changed code plus the programs + techiques folders, and compile config files should suffice. The only merge required would be in vs.config. Overall I think this is still not a bad time for merging before the branches drift too much apart.

[safemode]

merging at any time wouldn't be a problem if klauss had the time to sync head changes back to his branch periodically. In any case, i'm sure he wants to double check his own work and make sure it's what he wants to use because as soon as it gets into trunk, it's going to get pounded and depending on how busy he is, he may not be around to commit the fixes to his code... and that can get annoying on fresh code.

If data side stuff isn't working with it, then that would probably have to be resolved prior to getting into trunk. You dont merge in a bunch of code that doesn't work and then hope to get it fixed after the fact.

[pyramid]

... it's going to get pounded ... and that can get annoying on fresh code.

You've got the point certainly. At least I'd appeal to merge trunk to gfxtechniques when code comes to a fairly polished state so that testing is easier. It's just my suggestions and at the end it's up to klauss anyway.

At least things look every time better. I forgot to say that the pics were taken off a testing system, not any in-game system and the lighting is borked. It came all out too dark.

[klauss]

Careful guys, I'm trying to sync with trunk, and there are tons of things to sync in data. So the next update will be a big BW sucker. If you're not in the mood for a big download, stick to rev 12323.

I'm only synching what's required to make things work, BTW. I want to be sure there are not big issues before I merge into trunk.

It's ok if I do merge... right?

BTW, chuck, yes, I meant exactly that: I know better than to underestimate your seriousness.

And PS2: don't worry about those config changes, I'll skim over those and leave only the bare minimum in the merge.

Edit: Ok, screw the bare minimum... I'll be copying the entire data folder. So it would be wisest to hold that "svn up".

[safemode]

How much in /data did you change in your own branch? Seems like it might have been easier for you to just grab a new pull of /data and copy and paste the changed files in your branch over and start from there.

but hey, that works.


On a side note. Since the graphics stuff is getting refactored, I really really really want to fix our vector mess.

We need a templated Vector class that will be of Double and Float types. That's it. But we do some weird preprocessor juggling of definitions to mimic a templated class, rather than just write one. I dont want to keep all the typedefs for it around either. Just reference it by vsVector<float> and vsVector<double> . For clarification purposes.

[vodalian]

Also presented is (TA-TA) the planet rings with proper z-buffering based on latest svn.

Sweet! Can't wait till the new win32 build!

[chuck_starchaser]

If there's anything I can help with, let me know; I'm terribly unfamiliar with the code, and don't have a working compiler; but I can write template classes from scratch no problem, given clear specifications.

[klauss]

I do have a vector template in the audio branch, BTW. Did you see it?
I only added what I needed, but I bet it can be extended/compatibilized to match current vectors.