project-navigation
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 - arisian

Pages: [1] 2 3 ... 7
1
The work I'm doing in the branch is a pretty major overhaul; there's no easy way to integrate just part of it into trunk.  I don't use codeblocks myself, so I haven't been keeping the project files up to date; they probably need to have some of the new source files added to them (eg. new .c and .h files in src/renderer/).  In term's of screenshots, here's one now.  Keep in mind, this is a "manufactured" screenshot, in that I've just arbitrarily created some lights in order to show off the shadows.  One is blue-ish and the other more orange so you can tell which shadows are being cast by which lightsource; lights in the actual game can be whatever color we want, though white (or close) is more realistic for most types of lightsource.

No lightmaps were used in this scene; in fact, I expect that the lightmaps will be removed alltogether by the time I'm done.  In the mean time, keep in mind that this is still very much a work-in-progress; the renderer-work branch isn't really intended to be a viable alternative to trunk for gameplay or testing at the moment.

2
Artwork / Re: New here. Want to help
« on: June 23, 2010, 02:47:30 pm »
Welcome to the forums, your models look great!

If you find that the MD2 format is limiting, the game also reads MD3 and OBJ models (at least in theory; I'm unsure if we actually have any in use at the moment).  I'm not that familiar with the advantages of the various formats myself, but if you run into issues with content you can't figure out how to get into the game, let me know.  I'm still in the process of improving the rendering system, so if there are features that you'd like to see, I can try to add them for you.

We definitely need talent like yours; as I'm sure you've noticed, the models we're using now are pretty low poly-count and lack normal-maps, as well as having a visual style that is sometimes a bit more cartoon-ish than the look-and-feel of the rest of the game (e.g. things like the soldiers with cigars in their mouths).

3
No, it should be fixed in the 2.3 branch, but I haven't fixed it in trunk yet.

4
The "shiny metal" stuff didn't make it into the 2.3 release; the only new graphical feature on the battlescape for 2.3 is the glow.  If the guns are glowing and the UFOs aren't I'm pretty sure it's due to missing files and not issues with the renderer.

5
The glow effect on the rifles in your "ufo04.jpg" screenshot look correct to me.  The lack of glow on the UFO itself indicates to me that either you didn't have the effect enabled, or you're missing the glow-textures for the UFO somehow.

The failure to load maps still has nothing to do with the shaders; whether they're on or off should have no effect whatsoever.

6
The issue with the failure to load the maps has nothing to do with your graphics card; if you look in the log, it says it can't find the proper tile to assemble the map.  Have you tried re-building the maps? 

The issue with models not being displayed properly is much more likely to be caused by the rendering code interacting with the ATI drivers; can you be more precise about what you're seeing there?  As usual, there's nothing in the logfile that indicates any sort of error.  If the only issue is that you can't easily see a difference, that may just be due to the fact that the changes are relatively subtle at the moment.  The most easily visible change is the soft-glow around the edges of emissive sources; for example, the bright green parts on the UFOs should appear to "glow" with GLSL and Postprocessing both enabled.

There's a much bigger visual difference in the renderer_work branch, but that code is nowhere near ready for prime-time yet; hopefully the 2.4 release will have pretty real-time shadows and lighting.

7
There were a few "optimizations" that I took out in places where I think they may have been skipping some cases that should have been handled.  Making them handle everything was the easiest way to fix it for the release, even if it's not the most optimal way to do so.

Alternatively, if you've never actually used postprocessing before, that would explain it, since postprocessing in the current implementation is known to be very expensive in terms of framerate.  I'm not quite sure why it's so slow, to be honest; it's something I'll try to fix if I can ever figure out what's causing it.

8
I think this should be fixed in the latest version in the 2.3 branch, but I'll disable that debug output entirely for the release version just in case.

9
Agreed, I just wanted to get it working any way possible for 2.3

10
Yes, I haven't done any work on 2.4, I'm concentrating on getting the 2.3 codebase patched for release.  I'll try to move the changes into 2.4 when I get a chance.

11
It's working now?  Hooray!  To answer your question, I changed a couple of things.  First, the only major "feature" I removed was the directional illumination of actors and other non-tile based entities.  They now look the way they used to in terms of lighting.  The glow maps are still used.

In terms of what fixed the issue, I'm still not really sure which of the changes I made actually did it.  I changed how glow was handled by multi-stage materials, but that only applies to brushes (it should fix a bug where glow would shine "through" other objects).  I also made several small changes to the code that is responsible actually rendering the glow effect in the hopes that one of them would fix the issue with the randomly glowing models.  I'm just glad that it seems to have done the trick; I really wanted to get this fixed before the 2.3 release.

If anyone else is still having issues with this (in the most recent 2.3 branch), please let me know as soon as possible so I can try to iron all the bugs out before the release.

12
For those with black models, how many dynamic lights are active?  (it's a counter near the bottom of the graphics menu)

13
I'm not sure what, if anything, the "multisample" flag actually *does* at the moment; it's not one of my features.  I'll try to take a look at the issue, though; for the record, I'm able to replicate something similar to this issue, but it's got nothing to do with the GLSL compiler errors you posted there.  I'm not sure why those are occurring; I haven't been able to replicate them, but they don't seem linked to the crash.  Are you running the newest version of the nvidia drivers?

14
Yeah, I'm still trying to figure out what's causing this; once I do that, I'm fairly confident I can fix it.  The problem is really that it seems very system-specific; I can't seem to replicate these "glow" issues on a ATI 4670 card (Windows XP, driver version 8.723).  This makes it very difficult to debug, since I can't tell what's wrong, and I can't tell if I've fixed it  ???

It might be helpful to me if people who are experiencing this issue could post the following:

1) Your system specs, including CPU, graphics card, driver version, operating system, and anything else you think might be relevant
2) A screenshot of the problem on your system, since it seems to look different for different people
3) A copy of your logfile
4) What conditions the problem does/doesn't happen under (e.g. does postprocessing on/off make a difference, or just realtime lighting?  Does it only happen under certain gameplay conditions?  Is it consistent, or does it seem to occur at random?)

Also, be sure that you're working from the most recent version of the 2.3 branch (since my first priority is getting that stable, that's where the changes will happen first).
I'll try to get this sorted out as quickly as possible; I appreciate everyone's patience with this.

15
Artwork / Re: Textures
« on: May 18, 2010, 03:22:11 am »
Actually, 1.0 is now super-shiny.  The new specularity-textures need to have values in the range 0-1 (well, 0-255, but that gets mapped to a float in the range 0-1 by your graphics card).  That means that with a texture, 1.0 really would be the maximum reflectivity.  The older system, which stored SPECULAR and HARDNESS values as material parameters, wasn't constrained to the range 0-1, since they could specify floating point values directly in the .mat files, which is why you could use bigger values.  The current "defaults" are actually set in R_EnableDynamicLighting() (because I didn't know about the #defines), and the default values are much lower than 1.0.  SPECULAR or HARDNESS values, if specified, will override the defaults; if a specularity and/or roughness texture is provided, that will override the SPECULAR or HARDNESS values.

Oh, and all the "accessory" textures get loaded automagically; so long as you follow the naming conventions, all you need to do is drop the new textures in with the old ones.  And I'll just mention again here that you don't always need to have all the textures be the same resolution; a 1x1 pixel specularity and/or roughness texture would be perfectly fine for an object that was uniformly shiny over it's surface.

Current defaults (hardcoded) are SPECULAR=0.25, HARDNESS=0.1;  the HARDNESS parameter controls how strongly the material reflects light, and the SPECULAR parameter controls how tightly focused the reflection is (ie. do you get a small "spot" of shine, or does the shine cover a larger area).  SPECULAR = 1.0 would mean a very tiny bright spot.

Pages: [1] 2 3 ... 7