|
12 | render | Feature Request | Low | Light Flare Occlusion | New | |
Task Description
Having light flares occlude behind objects would allow more detailed flares to be used. The following is a screenshot from Mass Effect, and is the back of the Normandy:
http://www.bioware.com/_commonext/images/me/screenshots/dlc/masseffect_01_1280x760.jpg If this were tried in Osirion with a regular light entity and a similar flare texture, it would be partially visible from behind surfaces, which is not the desired effect as the light shouldn't be making a flare if it's seen from behind a wall. This is also the reason why most of the flares in Osirion are circular, because a horizontal flare(also known as the 'film-style' flare) is too difficult to get right when it can move in all angles. In the end, this might actually lower performance a tiny bit because each flare has to be checked if it's behind a surface, but if a flare is completely blocked, it shouldn't render at all which would make up for the loss. Q3 has several methods of doing this, including a timed fade, real fade, and instant. Timed fade: when a flare becomes visible, begin rendering the quad and slowly increase its size and alpha from 0 until it reaches the size indicated by the entity. The rate of size increase is based on a simple timer.
Real fade: like timed fade, begin rendering the quad once visible but instead of using a fixed timer, only increase the size and alpha depending on how much of the flare is in view. I believe this is done via the size indicated in the entity, and is based on how much of it at its full size is visible(I'm guessing an invisible quad at max size is used to test this). This method is best because it can be tweaked to allow the flare to overlap the surfaces in front of it by a small amount, making it look very realistic.
Instant: the flare is instantly visible at max size and alpha as soon as the light entity's origin is visible by the camera. |
|
11 | core | Feature Request | Low | OBJ support | Closed | |
Task Description
OBJ support would be great for sub-models. Radiant's brushexport2 can export brushes into this format, in addition to natively supporting it in the editor itself. Wavefront .obj file Wikipedia article:
https://secure.wikimedia.org/wikipedia/en/wiki/Wavefront_.obj_file Info page including a long list of sample obj files:
http://people.sc.fsu.edu/~jburkardt/data/obj/obj.html |
|
10 | core | Bug Report | Medium | Sub-model clip brushes are not inherited by parent mode ... | Closed | |
Task Description
If you use a collision model on a sub-model(called with misc_model or some other way), it does not include the clip brushes used in the sub-model if collision models are activated in ships.ini(or equivalent). |
|
9 | render | Bug Report | Low | Entity axis transformation is not applied to Cubemap te... | New | |
Task Description
Symptom: When rotating the ship, cubemap reflections are not rotated in effect, and stay in the default rotation axis. |
|
8 | client | Bug Report | Low | Alt-Enter fails to drop key modifier | Closed | |
Task Description
Using Alt-Enter to change from windowed mode to fullscreen, fails to drop the 'Alt' key modifier, meaning no other input will be accepted until this key is pressed again. |
|
7 | src | Bug Report | Medium | Rotated misc_models render in wrong positions. | Closed | |
Task Description
A misc_model that has been rotated in certain ways does not render correctly in-game(at least when it uses a .map as the model). The expected behavior should be how it appears in Radiant. In my testing:
A simple Z-axis rotate renders fine. Any other complex rotations, like Y-axis rotations cause it to rotate(as expected), but the origin is in the wrong place. So, theoretically, any rotation that does not move the misc_model's referenced model's origin should work fine. Any other will break. The latest committed version of the pirate juggernaut has misc_models with this problem, so that can be used as a test case. |
|
6 | render | Feature Request | Low | Hardware Workaround Scripts | Closed | |
Task Description
Despite the renderer being written very well and to the spec, certain hardware has trouble doing functions reported to be supported by the driver. I propose an ini file that the engine reads directly after loading all standard configuration files. This ini file instructs the engine to make specific checks and if they pass, execute a configuration file. The workaround handling being outside the engine allows future changes in the event that new hardware requires a workaround, without requiring recompiling the engine. Attached are proposed example files. |
|
5 | core | Bug Report | Low | 'give ship x' while moving makes player unable to contr... | Assigned | |
Task Description
At random, if you use 'give ship' while your ship is moving, you can be trapped in a state where you cannot turn or move in any direction. You are still given the new ship, however, and if you use 'give ship' a few more times, you can recover from the problem. Leaving this as low-priority since 'give ship' is technically a cheat. Setting this as category 'src' because the cause is unknown. |
|
4 | render | Planned Feature | Low | Z-Fail Stencil Shadows | New | |
Task Description
If a real-time shadowing method is to be used, sharp stencil shadows would be more in-line with the game's visual style. It apparently can be done with very little code. |
|
3 | render | Bug Report | Low | Merged patch mesh points produce bad results on Intel | New | |
Task Description
If multiple patch mesh points are in the same place(like on many windows), certain polygons are lit incorrectly on Intel hardware. Shot taken from netbook with Intel 945G chipset. |
|
2 | client | Bug Report | Medium | Skyboxes rendering junk on random sides on Intel | Closed | |
Task Description
For some reason, a random side(or two) of the skybox renders complete nonsense. This only seems to happen on Intel cards. I have attached a shot taken from my netbook which has an Intel 945G chipset. |
|
1 | src | Bug Report | Very Low | Sample Task | Closed | |
Task Description
This isn't a real task. You should close it and start opening some real tasks. |
