0008282: Settings PRIM_NORMAL, PRIM_SPECULAR, PRIM_ALPHA_MODE, not implemented

(0032513)
UbitUmarov (administrator)
2018-01-22 12:15

Yes, Set is a bit more complex to add that Get on our materials code.

so still on TODO :(

(0032534)
aiaustin (developer)
2018-02-05 06:37
edited on: 2018-02-05 06:40

Some work on the Ruth 2.0 mesh body and nail attachment specularity is related to this....

https://github.com/Outworldz/Ruth/issues/22#issuecomment-363102311 [^]

I wonder if the OpenSim side could support the functions and constants and, for now, have no effect... in order that scripts compile without error and without needing special OpenSim variants.

(0032535)
UbitUmarov (administrator)
2018-02-05 07:14

Think is all there, but Set will report error parsing those parameters
i could make it silence ignore them, but that could make things very confusing for any other scripter not following this discussions.

(0032536)
aiaustin (developer)
2018-02-05 07:57
edited on: 2018-03-13 02:35

Point taken @Ubit ... I was just trying to get things so that as Ruth 2.0 parts appear in OpenSim the scripts are ready to go if or when the SET functions are made to work, rather than such parts needing to have their embedded scripts changed.

(0032592)
aiaustin (developer)
2018-03-13 02:35
edited on: 2018-03-19 06:58

I note some scripts for Ruth 2.0 have to have temporary workarounds to avoid this error... its a pity to start to get lots of new content out there that will need fixing later...

// Currently, llSetLinkPrimitiveParams(0,[ PRIM_SPECULAR...] has a bug. It will trigger
// an error in the script if it tries to execute the function.

(0032626)
UbitUmarov (administrator)
2018-03-31 18:54
edited on: 2018-04-05 04:07

I did make some changes to materials and add support for PRIM_NORMAL, PRIM_SPECULAR, PRIM_ALPHA_MODE on Set functions.

Note this was done on branch httptests, not master, and this needs .net4.6 (or mono 5x)

This code needs more changes, and may still have issues.

Avoid changing materials in diferent llSet* commands. Viewers may get informed of changes on each line, and may ask for materials that where meanwhile removed by the next command’s changes, but should work, just wasted bandwith and a possible warning on log about unknown material.

Note also that a change waits some 2 minutes before sending new materials to grid assets DBs. If region crashes or has a problem meanwhile, they are lost. But well, a region crash is already a problem :)

Also, as before, material IDs are not really unique, there is a small but not null chance of different materials getting same ID, and so assumed to be equal, this is a issue to try to fix later.

(0036113)
TyphaineArtez (reporter)
2020-01-19 13:05

I get back on this ticket :)

If I understood well, each time a script modifies material properties, a new rendered material asset is created on the server? If yes, I understand the reticense on applying them.

I have notice that in SL, when changing material properties, the render is not *always* immediate, and not related to sim load. So that gave me an idea for an implementation:

When the viewer sends the new settings, it's put in a worklist of data (without render computation) associated to each asset it's applied on.

When the first request is sent to the simulator, a timer is set (something like 1 or 2 seconds, configurable in .ini). No stored asset creation is made in the database, only sent back to the viewer. When the timer gets over, the last loaded settings are used to create the asset.

Could this work?

If I get more info on what you have done (I am not sure to understand how you did it and what it implies), I will make a test if the current httptests branch contains your modifications.

(0036114)
BillBlight (developer)
2020-01-19 15:16
edited on: 2020-01-19 15:17

If you see Ubit's post above yours, this was implemented(over nine months ago) ... and is in the latest release

(0036132)
TyphaineArtez (reporter)
2020-01-21 12:54

I tried with the released opensim-0.9.1.0, the script does not bring any error when using llSetPrimitiveParams(), but nothing happens. As my test applied on object touch, I could try several calls.

So I am not sure it's fully implemented or it's on the released branch.

(0036133)
UbitUmarov (administrator)
2020-01-21 13:18

it is on release

(0036198)
TyphaineArtez (reporter)
2020-02-09 08:56

Ok it's on release, and using llSetLinkPrimitiveParamsFast() does not bring an error on the simulator, but commands have no effect (normal and specular settings on prims are not set).

(0036199)
UbitUmarov (administrator)
2020-02-09 10:15

just did test (example on mantis 8156)
default
{
    state_entry()
    {
        llSetLinkPrimitiveParamsFast(LINK_SET,
        [
            PRIM_TEXTURE, ALL_SIDES,
                "a39f9048-c04f-48c8-b5f9-d7eea368075f",
                <2,2,0>, <0,0,0>, 0.0,

            PRIM_NORMAL, ALL_SIDES,
                "2de71d6d-e20c-46a2-b9fc-5e3b2b1d9cc0",
                <2,2,0>, <0,0,0>, 0.0,

             PRIM_SPECULAR, ALL_SIDES,
                "5c9ef80f-0de5-4e3e-9049-826aa741f7cb",
                <2,2,0>, <0,0,0>, 0.0,
                <1,.5,1>, 64, 0
        ]);
    }
}

and worked fine

(0036200)
UbitUmarov (administrator)
2020-02-09 10:58

well looking to your example, you use "" for texture. That does not work. It removes the respective map. All "" and alpha mode 1 removes the material

(0036201)
UbitUmarov (administrator)
2020-02-09 11:18

however i did found a issue, now fixed
if on the scrip above PRIM_SPECULAR had texture "" the entire material was lost.
not anymore ( i hope )

(0036202)
TyphaineArtez (reporter)
2020-02-09 11:23

Thank you for testing, indeed you are right, it works (at least for a simple case of setting the normal map texture)!

I will checkout the issue you mentionned, as I guess the fix wont be available before the next OS release for the major part of users.

(0036203)
TyphaineArtez (reporter)
2020-02-09 11:42

Although the most parts are fixed on 0.9.1.1, I let the issue fixed on master code, due to the bug found by Ubit and fixed only in dev code: `if PRIM_SPECULAR has texture "" the entire material is lost.`

Notes
(0032513) UbitUmarov (administrator) 2018-01-22 12:15	Yes, Set is a bit more complex to add that Get on our materials code. so still on TODO :(

(0032534) aiaustin (developer) 2018-02-05 06:37 edited on: 2018-02-05 06:40	Some work on the Ruth 2.0 mesh body and nail attachment specularity is related to this.... https://github.com/Outworldz/Ruth/issues/22#issuecomment-363102311 [^] I wonder if the OpenSim side could support the functions and constants and, for now, have no effect... in order that scripts compile without error and without needing special OpenSim variants.

(0032535) UbitUmarov (administrator) 2018-02-05 07:14	Think is all there, but Set will report error parsing those parameters i could make it silence ignore them, but that could make things very confusing for any other scripter not following this discussions.

(0032536) aiaustin (developer) 2018-02-05 07:57 edited on: 2018-03-13 02:35	Point taken @Ubit ... I was just trying to get things so that as Ruth 2.0 parts appear in OpenSim the scripts are ready to go if or when the SET functions are made to work, rather than such parts needing to have their embedded scripts changed.

(0032592) aiaustin (developer) 2018-03-13 02:35 edited on: 2018-03-19 06:58	I note some scripts for Ruth 2.0 have to have temporary workarounds to avoid this error... its a pity to start to get lots of new content out there that will need fixing later... // Currently, llSetLinkPrimitiveParams(0,[ PRIM_SPECULAR...] has a bug. It will trigger // an error in the script if it tries to execute the function.

(0032626) UbitUmarov (administrator) 2018-03-31 18:54 edited on: 2018-04-05 04:07	I did make some changes to materials and add support for PRIM_NORMAL, PRIM_SPECULAR, PRIM_ALPHA_MODE on Set functions. Note this was done on branch httptests, not master, and this needs .net4.6 (or mono 5x) This code needs more changes, and may still have issues. Avoid changing materials in diferent llSet* commands. Viewers may get informed of changes on each line, and may ask for materials that where meanwhile removed by the next command’s changes, but should work, just wasted bandwith and a possible warning on log about unknown material. Note also that a change waits some 2 minutes before sending new materials to grid assets DBs. If region crashes or has a problem meanwhile, they are lost. But well, a region crash is already a problem :) Also, as before, material IDs are not really unique, there is a small but not null chance of different materials getting same ID, and so assumed to be equal, this is a issue to try to fix later.

(0036113) TyphaineArtez (reporter) 2020-01-19 13:05	I get back on this ticket :) If I understood well, each time a script modifies material properties, a new rendered material asset is created on the server? If yes, I understand the reticense on applying them. I have notice that in SL, when changing material properties, the render is not always immediate, and not related to sim load. So that gave me an idea for an implementation: When the viewer sends the new settings, it's put in a worklist of data (without render computation) associated to each asset it's applied on. When the first request is sent to the simulator, a timer is set (something like 1 or 2 seconds, configurable in .ini). No stored asset creation is made in the database, only sent back to the viewer. When the timer gets over, the last loaded settings are used to create the asset. Could this work? If I get more info on what you have done (I am not sure to understand how you did it and what it implies), I will make a test if the current httptests branch contains your modifications.

(0036114) BillBlight (developer) 2020-01-19 15:16 edited on: 2020-01-19 15:17	If you see Ubit's post above yours, this was implemented(over nine months ago) ... and is in the latest release

(0036132) TyphaineArtez (reporter) 2020-01-21 12:54	I tried with the released opensim-0.9.1.0, the script does not bring any error when using llSetPrimitiveParams(), but nothing happens. As my test applied on object touch, I could try several calls. So I am not sure it's fully implemented or it's on the released branch.

(0036133) UbitUmarov (administrator) 2020-01-21 13:18	it is on release

(0036198) TyphaineArtez (reporter) 2020-02-09 08:56	Ok it's on release, and using llSetLinkPrimitiveParamsFast() does not bring an error on the simulator, but commands have no effect (normal and specular settings on prims are not set).

(0036199) UbitUmarov (administrator) 2020-02-09 10:15	just did test (example on mantis 8156) default { state_entry() { llSetLinkPrimitiveParamsFast(LINK_SET, [ PRIM_TEXTURE, ALL_SIDES, "a39f9048-c04f-48c8-b5f9-d7eea368075f", <2,2,0>, <0,0,0>, 0.0, PRIM_NORMAL, ALL_SIDES, "2de71d6d-e20c-46a2-b9fc-5e3b2b1d9cc0", <2,2,0>, <0,0,0>, 0.0, PRIM_SPECULAR, ALL_SIDES, "5c9ef80f-0de5-4e3e-9049-826aa741f7cb", <2,2,0>, <0,0,0>, 0.0, <1,.5,1>, 64, 0 ]); } } and worked fine

(0036200) UbitUmarov (administrator) 2020-02-09 10:58	well looking to your example, you use "" for texture. That does not work. It removes the respective map. All "" and alpha mode 1 removes the material

(0036201) UbitUmarov (administrator) 2020-02-09 11:18	however i did found a issue, now fixed if on the scrip above PRIM_SPECULAR had texture "" the entire material was lost. not anymore ( i hope )

(0036202) TyphaineArtez (reporter) 2020-02-09 11:23	Thank you for testing, indeed you are right, it works (at least for a simple case of setting the normal map texture)! I will checkout the issue you mentionned, as I guess the fix wont be available before the next OS release for the major part of users.

(0036203) TyphaineArtez (reporter) 2020-02-09 11:42	Although the most parts are fixed on 0.9.1.1, I let the issue fixed on master code, due to the bug found by Ubit and fixed only in dev code: `if PRIM_SPECULAR has texture "" the entire material is lost.`

Issue History
Date Modified	Username	Field	Change
2018-01-22 00:53	TyphaineArtez	New Issue
2018-01-22 11:57	Sheera Khan	Relationship added	related to 0008156
2018-01-22 11:59	Sheera Khan	Relationship added	related to 0008084
2018-01-22 12:15	UbitUmarov	Note Added: 0032513
2018-02-05 06:37	aiaustin	Note Added: 0032534
2018-02-05 06:38	aiaustin	Note Edited: 0032534	View Revisions
2018-02-05 06:40	aiaustin	Note Edited: 0032534	View Revisions
2018-02-05 07:14	UbitUmarov	Note Added: 0032535
2018-02-05 07:57	aiaustin	Note Added: 0032536
2018-03-13 02:35	aiaustin	Note Added: 0032592
2018-03-13 02:35	aiaustin	Note Edited: 0032536	View Revisions
2018-03-19 06:58	aiaustin	Note Edited: 0032592	View Revisions
2018-03-31 18:54	UbitUmarov	Note Added: 0032626
2018-04-05 04:07	aiaustin	Note Edited: 0032626	View Revisions
2020-01-19 13:05	TyphaineArtez	Note Added: 0036113
2020-01-19 15:16	BillBlight	Note Added: 0036114
2020-01-19 15:16	BillBlight	Note Edited: 0036114	View Revisions
2020-01-19 15:17	BillBlight	Note Edited: 0036114	View Revisions
2020-01-21 12:54	TyphaineArtez	Note Added: 0036132
2020-01-21 13:18	UbitUmarov	Note Added: 0036133
2020-02-09 08:56	TyphaineArtez	Note Added: 0036198
2020-02-09 10:15	UbitUmarov	Note Added: 0036199
2020-02-09 10:58	UbitUmarov	Note Added: 0036200
2020-02-09 11:18	UbitUmarov	Note Added: 0036201
2020-02-09 11:23	TyphaineArtez	Note Added: 0036202
2020-02-09 11:42	TyphaineArtez	Mono Version	Other => 6.x
2020-02-09 11:42	TyphaineArtez	Note Added: 0036203
2020-02-09 11:42	TyphaineArtez	Status	new => resolved
2020-02-09 11:42	TyphaineArtez	Fixed in Version	=> master (dev code)
2020-02-09 11:42	TyphaineArtez	Resolution	open => fixed
2020-02-09 11:42	TyphaineArtez	Assigned To	=> TyphaineArtez