discussion ticket - hatching texture regression about 3dstreet HOT 4 CLOSED

the material component stores the texture path directly, making it hard to update

In theory, this should not happen. Only if user change the parameters of the materials on the scene manually. or the component data was changed in the Js code during scene initialization. Because I made a check in json-utils that if the component information is present in the mixin that is applied to the element, then do not save it in JSON. But it seems that this does not always work correctly, I can see this example with markup

from 3dstreet.

should we consider letting users modify scenes only through a higher level street component that stores data in the same form as streetmix json with segment type and variants on those segments? that would empower us to make updates to textures or other elements of a segment without needing to modify user scene data to support the updates.

But what if the user wants to change the segment elements - any of the components - position, rotaion, material, etc? Then this information still needs to be saved in JSON.
But we can make a high-level component for streets/segments and use information from it to initially load the scene. And store information in JSON only for elements that have been changed or added by the user. I'm still thinking about how this can be done, but it would greatly reduce the JSON size. Maybe we don’t even have to create additional components, but use streetmix data.
And there is also a question - what to do with animated elements that move around the scene. We can offer random animation if it is enabled. That is, do not save the position of all animated objects, but generating them randomly while scene load

from 3dstreet.

the material component stores the texture path directly, making it hard to update

In theory, this should not happen. Only if user change the parameters of the materials on the scene manually. or the component data was changed in the Js code during scene initialization. Because I made a check in json-utils that if the component information is present in the mixin that is applied to the element, then do not save it in JSON. But it seems that this does not always work correctly, I can see this example with markup

No, in this case with dividers saving data works correctly. Alternatively, to fix it on older scenes, we could add repeat information in material to the divider mixin rather than aframe-streetmix-parser.js.
...No, I tried adding data to the mixin inside assets.js, but the data is applied to the element from JSON. In the case of divider, the material:repeat property is calculated based on the street length.
I can add a check to json-utils when loading from JSON - if the property is present in the mixin, then use the value from the mixin. Then using repeat in the mixin inside assets for the default street length can make a better display option for the divider

from 3dstreet.

But we can make a high-level component for streets/segments and use information from it to initially load the scene. And store information in JSON only for elements that have been changed or added by the user. I'm still thinking about how this can be done, but it would greatly reduce the JSON size. Maybe we don’t even have to create additional components, but use streetmix data.

I think it's a good idea to do this. This will eliminate the need for versioning in many cases

from 3dstreet.