I've been trying to use the groupID shader uniform in a fragment shader to select the same decal for all ships in a group but running this shader in an oxp causes Oolite to generate this error in the log:
// Choose a decal based on the GroupID int from Oolite
float tempvar = float(GroupID);
float DecalSelect = mod(tempvar, 4.0) / 4.0;
float offset = floor(DecalSelect * kDecalCount) / kDecalCount;
decal_TexCoord.s += offset;
it all seems to run fine in Rendermonkey but Oolite doesn't seem to like me trying to send the groupID int to the shader, is there anything i'm obviously doing wrong?
i've uploaded an example oxp here http://www.box.net/shared/ghom84gdlb that will demonstrate the error
Last edited by Griff on Sun Aug 30, 2009 10:39 pm, edited 1 time in total.
...but Oolite doesn't seem to like me trying to send the groupID int to the shader, is there anything i'm obviously doing wrong?
i've uploaded an example oxp here http://www.box.net/shared/ghom84gdlb that will demonstrate the error
I think you are doing nothing wrong but the way groups are handled is changed. Until 1.72 the groupID field told who belonged to the same group. To find group members Oolite had to check all ships to see who belonged to that group.
In 1.73 this has changed. Groups are special objects now attached to the ship. I noticed that groupID is removed completely. So the error messages make sense. Although I don't see a quick solution.
There are two groups now: group and escortGroup. I think you are interested in the later. Group name is by default "escort group" but you can give the leadship a script to change that name to a random selected groupname. But I don't know to little of shaders to know if this is any useful for you.
e.g. in the console you can select a ship and type: player.ship.target.escortGroup.name = "Griffs group" and the group belongs to you. (at least by name)
Thanks Eric, your explanation makes sense, it's not a big issue if groupID isn't available to the shader anymore, i can set a standard decal for escorts in their shipdata.plist
edit: Just to confirm your detective work Eric, i just dusted off an old install of Oolite 172.2 and ran the shader in that and it worked OK. thanks again for your help, i haven't tried to use an 'int' in a shader before so i was wondering if i'd make some sort of error in the shader code.
“Unpermitted method” comes from the new whitelisting mechanism – if it isn’t in one of the shader_foo_binding_methods lists in whitelist.plist, you can’t bind to it. The fact that the method no longer exists is a side issue. :-)
Re-adding a groupID method for bindings would be possible, but I want to investigate a more flexible approach to this sort of thing: making non-binding uniforms settable by JS scripts.
What would be great would be a way of sharing randomly generated vec3's and floats amongst all the ships in the group so the shaders could re-colour them all with the same theme.
Ahruman, groupID is still listed in the whitelist.plist in v1.73, line 309 in the shader_ship_binding_methods incase you need to remove it in the next update, also, "alertCondition" is in the list too and i think that comes up with the same unpermitted error if you try and use that in a shader too.
sorry, i should have mentioned that the alertcondition binding generates the error but still works OK in game. i've got an oxp where the colour of the illumination map changes to match the alert level on the players ship which uses the alertcondition binding, for some reason box.net won't allow me to upload at the moment
Last edited by Griff on Sun Aug 30, 2009 11:02 pm, edited 1 time in total.
Good news, everybody! I’ve confirmed that the alertCondition problem can’t possibly be happening. Or at least, isn't happening for the reason I thought it might be. It also doesn’t happen at all on my system.