|
37 | Project::OSiRiON | render | Bug Report | High | Colors are randomly broken on open-source 'radeon' and ... | Closed | |
Task Description
Using an ATI Radeon HD 5770. Mesa 7.10. The colors for all environment-mapped surfaces(which means nearly all model surfaces) are randomly chosen when the renderer begins. The colors that are used are out of all the colors used by the models, rather than some random color. Also, it appears to be only entire materials that are switching to the wrong color, rather than per-surface. How to reproduce: Open up colors.shader, and comment(//) the 'environment' part of grey25, and run the game. You will see grey25 as the color it's supposed to be, only with its envmap fixed. My thoughts: It's either a bug in the driver or some logic error in the fragment drawing code that's only manifesting on the radeon driver. This may also affect other drivers that use Mesa, but as yet radeon is the only one that I have seen that has this issue. EDIT: This bug also occurs on the nouveau driver for nvidia. Perhaps Gallium3D is at fault? |
|
98 | Project::OSiRiON | render | Planned Feature | High | Material texture stages | In progress | |
Task Description
To ease the transition to a multitexturing rendering environment, I propose that we fully adopt Quake 3 shader scripting. Currently, we support a simpler version with a single texture stage in mind. DONE - Support for material with multiple layers TODO - OpenGL multitexture support - Improve syntax Exmaple of current implementation: shader/path/name { qer_editorimage path/to/texture { map path/to/texture entity } { map path/to/glow_texture fullbright blendfunc blend } } --------------------------------- Quake 3: shader/path/name { qer_editorimage path/to/texture other_keywords { map path/to/texture } { map path/to/texture2 blendfunc ... } |
|
2 | Project::OSiRiON | 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. |
|
7 | Project::OSiRiON | 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. |
|
10 | Project::OSiRiON | 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). |
|
41 | Project::OSiRiON | render | Feature Request | Medium | LOD entity keys + Automatic patch LOD | New | |
Task Description
The engine needs a way to be able to use a LOD system for performance reasons. I propose a method for this: all brush entities(except worldspawn and misc_model) will have a 'lod' key. The existence of this key in the entity(as in, if it's actually set) tells the engine to enable LOD on the entity. The value for the LOD key would be an integer of 0 through 3. A value of 3 tells the engine to only render the brushes at 75% and above of the detail LOD distance. A value of 2 renders at 50-75%. A value of 1 renders at 25-50%. 0 renders at 0-25% distance. If the key is not set, the brushes will render at all distances(unless set to detail). This allows two things: Patch meshes get LOD, and LOD gradually degrades with distance. An alternative would be in patch loading. At model load, bake 4 levels of LOD for the patch meshes into the model, and apply the same rules as above. This may not be desirable because some patch meshes may be required to stay at full LOD for specific reasons. The only downside to this is that it requires more memory to store the LOD models, but it would cut down on polygon count at render time significantly. |
|
73 | Project::OSiRiON | src | Bug Report | Medium | testmodel primary/secondary colors set incorrectly | Closed | |
Task Description
When using testmodel, the secondary color seems to be copied from the primary color rather than cl_colorSecond. |
|
91 | Project::OSiRiON | render | Feature Request | Medium | Extend spawnflags for Lights/Flares/Particles to includ ... | Closed | |
Task Description
Lights, Flares, and Particle system entities are allowed to use entity color for coloring their graphics, but entitysecond and entitythird are not available. DONE - Particlesystems can be set to entity second from inside the script - entity_second spawnflag for lights - entity_second spawnflag for flares - entity_second spawnflag for particle systems - entity_third can be enabled by setting both entity and entity_second. |
|
92 | Project::OSiRiON | src | Feature Request | Medium | Clean up of material, light, flare and particle color ... | New | |
Task Description
Clean up and homogenize material, light, flare, engine and particle color types and flags. Those fx can be triggered by engine states (trigger_impulse, trigger_engine, trigger_destroyed, ..) The color can be set as color_entity, color_entity_second, color_entity_third, color_engine, ... TODO - review/refactor: lights, flares, materials, and particles should have the some options for triggers and colortypes. The parameter names in .map file classes and .material files should be the same |
|
3 | Project::OSiRiON | 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. |
|
4 | Project::OSiRiON | 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. |
|
5 | Project::OSiRiON | 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. |
|
6 | Project::OSiRiON | 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. |
|
9 | Project::OSiRiON | 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. |
|
11 | Project::OSiRiON | 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 |
|
12 | Project::OSiRiON | 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. |
|
35 | Project::OSiRiON | render | Planned Feature | Low | GLSL Shader program support | New | |
Task Description
Extend the current Material system to support GLSL shader programs. Normal map, specular map and glow map support. |
|
38 | Project::OSiRiON | render | Feature Request | Low | Distance LOD for Patch Meshes | Closed | |
Task Description
Patch Meshes currently render at a fixed subdivisioning at all distances, making the extra polys sometimes useless when the player is far enough away. Distance LOD would drastically reduce the amount of polygons generated by patch meshes in the distance. This would probably result in some accuracy issues when two patch meshes are next to each other, but probably wouldn't be seen due to their distance. This is an acceptable tradeoff for increased performance(and it would have a configurable minimum subdivision level). As I understand it though, patch meshes are presubdivided as the model is loaded, which would make this difficult to implement. As with a few of my other feature requests, there is example code in ioquake3 that does this. |
|
60 | Project::OSiRiON | src | Feature Request | Low | Thrust Point Entities | New | |
Task Description
For finer control of the ship, thrust points should be defined. Instead of the ship being pushed from its origin point, thrust entities would define where the force against the ship is coming from. This would allow for more realistic control. If more than one entity is used, the thrust power is split between them, or defined by percentage specifically with entity keys. |
|
61 | Project::OSiRiON | src | Required Media | Low | Jump exit gives mostly random thruster setting | Closed | |
Task Description
Upon exiting a jump(as in, appearing in the target system) using a jump gate or the jump command, the player starts with a thruster setting above 0. The value is mostly random. |
|
63 | Project::OSiRiON | src | Feature Request | Low | Port to Raspberry Pi | New | |
Task Description
port osi to raspberry pi |
|
64 | Project::OSiRiON | data | Required Media | Low | Tsu-Khan Texture Set | New | |
Task Description
Tsu-Khan needs a set of textures. |
|
65 | Project::OSiRiON | render | Planned Feature | Low | Material blend modes. | In progress | |
Task Description
Shaders need a way to enable different OpenGL blending modes, like Quake 3's "blendFunc". This will allow special effects like light beams and 3d exhaust effects. DONE - blenfunc none - blendunc add - blendfunc blend TODO - blendfuncGL_SOMETHING GL_SOMETHING - blendfunc filter? |
|
72 | Project::OSiRiON | client | Feature Request | Low | Allow mouse to directly control steering like joystick. | New | |
Task Description
I propose a key bind(toggle) to allow the ship to be steered via the mouse in the same method as the joystick: directly steering based on relative mouse position(locking the cursor in the center of the screen). |
|
74 | Project::OSiRiON | render | Bug Report | Low | Scene drawing is not skipped when testmodel screen is o... | New | |
Task Description
If the testmodel window is opened, the current scene is still drawn. Fixing this would provide quite an optimization. |
|
75 | Project::OSiRiON | render | Feature Request | Low | Fade for strobe lights. | New | |
Task Description
Fade-out of strobe lights should occur by default, with an optional float fade time and boolean fade spawnflag. |
|
76 | Project::OSiRiON | render | Bug Report | Low | Patch meshes with texcoords generated from Radiant's 'c... | New | |
Task Description
For an example of this, take a look at the Talon's main guns. |
|
77 | Project::OSiRiON | data | Required Media | Low | Better fonts | New | |
Task Description
Osirion needs some better fonts besides the ugly monospaced font it uses right now. Perhaps the current font should just be used for the console? I recommend this font as it's licensed under the CC and doesn't look half bad: http://openfontlibrary.org/font/jura |
|
78 | Project::OSiRiON | core | Bug Report | Low | Entire model fails to load when a submodel is invalid | Closed | |
Task Description
An easy way to test this is to erase the entire contents(as in, ascii text) of any submodel. The whole model will fail to load when this submodel is tried by the loader. |
|
93 | Project::OSiRiON | render | Feature Request | Low | Allow currently loaded skybox to be bound as a texture. | New | |
Task Description
We need this in order to clean up the material drawing(specifically the environment mapping section). This could also possibly enable us to use the skybox cubemap for nice reflection effects. |
|
101 | Project::OSiRiON | data | Required Media | Low | Dagon Texture Set | New | |
Task Description
House Dagon needs a set of textures. |
|
102 | Project::OSiRiON | src | Bug Report | Very Low | Variable-length arrays preventing compilation with Clan ... | Closed | |
Task Description
When compiling with clang, it will run until stopping with an error on mapfile.cc: In file included from mapfile.cc:1: mapfile.cc:293:36: error: variable length array of non-POD element type 'math::Vector3f' math::Vector3f patchvertices[rows][columns]; ^ mapfile.cc:294:37: error: variable length array of non-POD element type 'math::Vector2f' math::Vector2f patchtexcoords[rows][columns]; ^ 2 errors generated. make[3]: *** [mapfile.lo] Error 1 make[3]: *** Waiting for unfinished jobs.... Clang isn't super-important, so I'm marking this as very low severity. In the future, someone might want to compile Osirion for FreeBSD, or another OS that uses Clang as the default compiler, so it might help to fix this problem. |