Progress

General discussion for players of Oolite.

Moderators: winston, another_commander

User avatar
Commander McLane
---- E L I T E ----
---- E L I T E ----
Posts: 9520
Joined: Thu Dec 14, 2006 9:08 am
Location: a Hacker Outpost in a moderately remote area
Contact:

Post by Commander McLane »

Ahruman wrote:
Commander McLane wrote:
Thanks for the information on the current state of the <key>smooth</key>-command. I guess that explains the weird behaviour of that command I have reported elsewhere.
I’m not sure which behaviour you’re referring to. The “darkening” thing isn’t related.
I was referring to my experience with smoothing my ship by inserting the <key>smooth</key><true/> into its shipdata. Apart from darkening it there is another issue: after I changed the value to <false/>--because I didn't like the darkening--the ship is still smoothed. So as long as I'm still working with 1.65 I guess I should take it out completely in order to restore the original state.

And sorry for the wrong number of 8-bit-RGB-colours. I mistakenly calculated 255^3 instead of 256^3. :oops:
User avatar
Selezen
---- E L I T E ----
---- E L I T E ----
Posts: 2530
Joined: Tue Mar 29, 2005 9:14 am
Location: Tionisla
Contact:

Post by Selezen »

Ahruman (et al) - is there any chance of being able to render the exhausts in the starting demo animations?
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

Possibly, but I’m not going to prioritize it.

In the mean time, here’s a the script I’m using to test the Griff Krait. Much like the traditional one, only it spawns them near the station to save work. (Name it script.js and put it in the addons folder.)

Code: Select all

// Configuration -- customize here
this.role = "griff_krait_rich_pirate";
this.count = 3;

// Standard attributes
this.name           = "Spawn-" + this.role;
this.author         = "Jens Ayton";
this.copyright      = "This script is hereby placed in the public domain.";
this.version        = "1.0.1";
this.description    = "Script to make several ships of a given role appear at the witchpoint after every jump."


this.willLaunch = function()
{
    system.legacy_addSystemShips(this.role, this.count, 1.0);
    LogWithClass("testscript.spawn", "Generated " + this.count + " " + this.role + " for testing purposes.");
}
By the way, Oolite 1.69, it should be possible to do something along the lines of:

Code: Select all

this.willLaunch = function()
{
    var ships = system.addShips(this.role, this.count, player.position);
    for (var i=0; i<someObject.length; i++)
    {
        ships[i].setAI("tumbleAI.plist");
    }
}
Obviously this isn’t helpful in the specific case of checking exhaust plumes, but for looking over a ship it should be handy. You could also use, say, route1patrolAI.plist to make normally piratical ships docile for inspection.

(I’m leaning towards keeping the AIs in the same form, or similar, and having an optional JS script attached to each NPC ship. JS scripts will be able to change AIs, change AI states, and force the AI to “think now” – more precisely, to set the time-until-next-AI-update to 0. With the ability for any script to boss any ship around, and the ability to iterate over escorts and subentities, this’ll allow for more complex and co-ordinated behaviour.)
Last edited by JensAyton on Mon Apr 09, 2007 2:19 pm, edited 1 time in total.
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

Slight update:

Code: Select all

// Configuration -- customize here
this.role = "griff_krait_rich_pirate";
this.count = 3;

// Standard attributes
this.name           = "Spawn-" + this.role;
this.author         = "Jens Ayton";
this.copyright      = "This script is hereby placed in the public domain.";
this.version        = "1.0.2";
this.description    = "Script to make several ships of a given role appear at the witchpoint after every jump."


this.willLaunch = function()
{
    var existing = system.countShipsWithRole(this.role);
    var count = this.count - existing;
    if (count > 0)
    {
        system.legacy_addSystemShips(this.role, count, 1.0);
        LogWithClass("griffkrait.spawn", "Generated " + count + " " + this.role + " for testing purposes.");
    }
    else
    {
        LogWithClass("griffkrait.spawn", "Not generating any " + this.role + " -- there are already " + existing + " in system.");
    }
}
Note: the if (count > 0) bit is necessary, because the game will try to add 4 294 967 296 + count ships if you pass a negative number. (Bug inherited from old scripting system, fixed for 1.69.)
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

Refactoring shader support. 1.69 will not support having a vertex shader in the shipdata.plist file and a fragment shader in an external file or vice versa. (I doubt anyone’s doing that.) It may not support having both shaders inline in shipdata.plist, either. Using external files for shaders is strongly reccomended for future development.

Yesterday I broke the startup demo screen, and in fixing it I tried having exhaust plumes there as per Selezen’s request. It didn’t work well, because of the way plumes track ship movement. It’d require rewriting it to rotate the camera around the ship instead of vice versa. I want to separate the demo code out of its current location, and might do that then.
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

(Now that I’ve got some assurance it will work under the GNU runtime…)

So, what’s this “refactoring shader support” in aid of, then? Well:
  • Cleaner separation of concerns in code, although this of course only affects you very indirectly, so you don’t really care.
  • Slightly better performance when multiple entities are using the same vertex shader/fragment shader combo. Since I intend to apply a standardised shader to ships with none specified (in “full shader mode” only, assuming the off/medium/full thing happens) this’ll matter somewhat. More efficient rendering too, come to think of it.
  • Probably also better ship-loading performance if either the vertex shader or fragment shader is currently in use, or has been recently.
  • Generalized “material” concept. It will probably be possible to set overall specular highlight attributes for a ship to use even when shaders are disabled, and to replace a texture in a model without making a copy of the model.
  • Uniform binding. Instead of a fixed set of properties mapped to a fixed set of uniform variable name, it will be possible to bind a uniform name to any ShipEntity attribute (getter method) which is a number (and probably vectors and quaternions as well). This will be set up in shipdata.plist, something like this:

    Code: Select all

    <key>shaders</key>
    <dict>
        <key>ahruman-texture-name-in-dat.png</key>
        <dict>
            <key>textures</key>
            <array>
                <string>ahruman-texture-used-by-shader.png</string>
            </array>
            <key>fragment_shader</key>
            <string>ahruman-fun-shader.fragment</string>
            <key>vertex_shader</key>
            <string>ahruman-fun-shader.vertex</string>
            <key>uniforms</key>
            <dict>
                <key>someNumber</key>
                <real>42.5</real>
                <key>numberOfShipsInRange</key>
                <dict>
                    <key>type</key><string>binding</string>
                    <key>value</key><string>numberOfScannedShips</string>
                </dict>
                <key>haveTarget</key>
                <dict>
                    <key>type</key><string>binding</string>
                    <key>value</key><string>getPrimaryTargetID</string>
                    <key>clamped</key><true/>
                </dict>
            </dict>
        </dict>
    </dict>
    In this example, the shader’s uniform numberOfShipsInRange uniform is set to the number of ships on the scanner, and haveTarget will be 1 if a target is selected, otherwise 0. (The “clamped” attribute limits it to the range 0..1.)

    Credit where credit’s due: this “binding” concept, which is niftier than it may at first appear, is based on the OpenStep/Cocoa/GNUstep framework’s concept of Key-Value Coding, and made possible by the awsomeness of the Objective-C language.

    A fullish list of bindable attributes will be published at a later date. The existing hard-coded bindings will be set up for compatibility purposes.
  • Hooks are in place for setting uniforms from JavaScript. This will mostly be useful for NPC scripts, I suspect.
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

New shader code checked in.

It brings out the worst in the current texture-handling code in terms of loading delays. My intended solution to that is to reintroduce the old idea of asynchronous (i.e., multi-threaded) texture loading. In doing this, I’m going to abandon the current approach of using NSImage under OS X and SDL_image for other platforms, because NSImage mucks about with textures with alpha channels in a way that’s problematic for shaders (and causes artefacts with text drawing), and SDL_image doesn’t appear to be thread-safe. I’m leaning towards using libpng, encapsulated so adding support for other loading paths will be practical.

What this means to you: if you’re using images in any format other than PNG in OXPs, stop it. If you have a real need to use something other than PNG, please explain why as soon as possible.
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

New texture code – which, as per the above, only handles PNG and takes advantage of multiple processors, as well as reducing the severity of loading delays on single-processor systems – is now used for text as well as shader stuff. (Using it for all textures on models will take a bit longer since I’m taking the opportunity to revamp handling of models. This will probably mean the face and vertex restrictions will be lifted in 1.69.)

Anyway, here’s a before-and-after of text rendering:
Image
This fixes the dark halos around text that have been there forever (probably only on OS X), although they’re not very noticeable at this size, and also benefits from mip-mapping.
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

I’m not dead, I’m just resting…

I’m working on separating out drawing of ships from their controlling logic. This is something I’ve wanted to do for a while, but it has become necessary now in order to fully implement the new material model.

Apart from new material options and mip-mapped textures by default, the change that’s most likely to affect OXP makers is a change to alpha handling: instead of sort-of working but not really, alpha channels will be completely ignored, as will the alpha output from shaders. This halves the number of triangles drawn for each ship (since the underlying rendering in grey has been removed), and improve rendering speed on low-end hardware. True alpha channel support will probably not be in the next testing or full release.

Also, when Oolite encounters a DAT file with no TEXTURES section, it currently generates UV maps and uses metal.png. Since this involves quite complex code and, as far as I know, is never actually used, this will be used and a single-colour material will be used instead (currently white, but I’ll probably change to glowing red so it’s easy to notice).
User avatar
johnsmith
Deadly
Deadly
Posts: 141
Joined: Fri Sep 22, 2006 10:32 am
Location: Teance
Contact:

Post by johnsmith »

Good work!!!!
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

Since I’ve been playing around with the sky, I added the ability to set the sky colours (in planetinfo.plist) with the extended syntax used for lasers and materials. The keys are sky_color_1 and sky_color_2, and these override the values specified in sky_rgb_colors.
User avatar
Commander McLane
---- E L I T E ----
---- E L I T E ----
Posts: 9520
Joined: Thu Dec 14, 2006 9:08 am
Location: a Hacker Outpost in a moderately remote area
Contact:

Post by Commander McLane »

Given the way in which the discussion about escape pods developes, I'd like to propose the introduction of a (short) countdown before launching the escape pod in the next version.
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

This week I took a stab at completely removing the vertex and face limits. Doing this properly turned out to be complex, so I’m saving it for a future release. In the mean time, to celebrate the fact that meshes now take much less memory, I’ve raised the limits to 500 veritices (from 320), 800 faces (from 512), and 8 materials (from 7).

Additionally, since front_metal.png and back_metal.png are identical, I’ve removed all references to the former in built-in models to the latter. If you’re using front_metal.png in anything, switch to back_metal.png. (The ballturret uses back_metal.png and does not need to be changed.)

I think I’ll focus on bug fixes and minor graphics tweaks over the next week or two and release 1.69 before getting back to JavaScript support.
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

Dear diary, today I have…
  • Reduced Oolite’s memory footprint slightly.
  • Reduced Oolite’s code size slightly.
  • Increased baseline frame rate on my system from around 30 FPS to around 50 FPS.
That last bit is Mac-specific, though.
User avatar
Star Gazer
---- E L I T E ----
---- E L I T E ----
Posts: 633
Joined: Sat Aug 14, 2004 4:55 pm
Location: North Norfolk, UK, (Average Agricultural, Feudal States,Tech Level 8)

Post by Star Gazer »

What do you consider were the main reasons for that improvement? - oh, and is that Oolite, Oolite-strict, no oxps, whatever - What is that frame rate relating to activity-wise? - also can you requote your Mac spec - just for reference!

Thanks! (in anticipation)
Very funny, Scotty, now beam down my clothes...
Post Reply