Skip to content
This repository has been archived by the owner on Feb 28, 2024. It is now read-only.

[BUG-230996] Terrain Textures 2 #8548

Open
sl-service-account opened this issue Jul 20, 2021 · 2 comments
Open

[BUG-230996] Terrain Textures 2 #8548

sl-service-account opened this issue Jul 20, 2021 · 2 comments

Comments

@sl-service-account
Copy link

sl-service-account commented Jul 20, 2021

Good . This is a looOOoong feature request explaining in great detail how the feature would work. Please make sure you have a drink and snack of your choice ready before proceeding.

 

This feature request is an update to improve how existing terrain textures are applied to regions. Most importantly it ensures that all SL viewers have a uniform viewing experience, as well as providing the creator better control of how textures are applied to the terrain of the region.

Using a similar method to terrain height maps, this feature will determine which blend of textures are most visible at a given inworld coordinate on the terrain. Then instead of using the current pseudo-random blend method to render textures on land, we define which textures are most visible at a given coordinate using a "texture visibility map".

For the terrain visibility map, this feature should use an image format that viewers already understand, and that can potentially be stored on the asset server to be applied at the region level via drag and drop, or converted into a unique asset type. I suggest the format be a PNG, as it allows for the controlling 4 channels (texture sets) of visibility, while using lossless compression. The four channels of RGBA would then define which terrain texture is most visible – 0 being the lowest, and 255 being the highest.

It would be NICE if we upgraded from the existing 256x256px height .raw map that is on regions currently, to 512x512px. Such an upgrade would allow defining which texture is most visible at increments of 0.5 meters on a region instead of every 1 meter. The upgrade isn't a requirement for the feature request, but it would be nice.

Another feature improvement is to define the texture scale of repeats in meters. Currently all terrains have a repeat of 12 meters, it would be nice to change this to something sane like 16 (because it divides into 256 nicely).

It would also be nice to allow the use of materials (speculars and normals) on terrain. Speculars and normals follow lock-step with repeats and terrain visibility. This would make for nice features such as wet land after a rain. "Blending" of materials may be troublesome.

 

A couple new viewer side features would have to be created to support this, some which could borrow functionality from existing viewer features.

The first is a "terrain painter". It could be a simplified version of the current terrain editor, but instead presenting an option for the four terrain textures as a pallet of "colors" (as defined by the existing estate options), a selection of brush sizes, brush shapes, and an option of brush strength. Painting doesn't need to happen in real time server side, it can happen client side and send an update to the region (and then viewers) when a painting session is finished. Or it could happen in real time with the same methods regions use now for terrain.

"Painting" a texture "color" with a brush, would make it more visible (push it's value up), while making other "colors" at the same pixel coordinate less visible (push their values down).

"Erasing" a texture "color" with a revert/erase feature, moves values closer to the region bake.

While we're in there building for this feature I would suggest allowing a new single "pixel" brush size control, instead the current smallest 9x9 grid, and making the brush indicator more flush with the land instead of the hovering above it as it does now.

When a viewer sees another region, it will have to download the Terrain Visibility Map in addition to the terrain height map. From there it will use client side calculations to render the visibility for terrain textures, similar to the existing land application now; but without any randomized blending components.

The estate terrain floater will require a few small adjustments. At the top it should have a drop-down selector or other UI element that selects the terrain version. Selecting a terrain version will determine the layout of the floater. Selecting Terrain Version 1, will use the classic floater. Selecting version two will change options to the existing floater:

  • Remove Terrain Elevation Ranges.
  • Add Upload and Download Terrain Visibility Maps.
  • Add Bake Terrain Visibility.
  • Add Specular and Normal Maps for terrain textures.

Server Side it would just have to store the following information at the region level:

  • Terrain Version: Tells the viewer which method of terrain rendering it should use. (1 or 2): 1 is Classic 2 is This Feature

  • Terrain Scale: User defined in meters. Sane limitations?, 2-128? Defaults to 12

  • Visibility Map: A texture UUID of the current map.

  • Baked visibility map: A texture UUID of the bake.

     


Additional Feature Creep:
Allow residents to change the terrain visibility of their own parcels using ONLY the estate defined textures, in the same way that residents can edit their terrain now. If this feature is added, make it an additional estate level option whether or not land owners could change the painted land.

New Region Land Asset: Create a specific type of asset that only estate managers and owners can apply to a region. This asset should function like any other SL asset with regards to permissions, and being sold on the Market Place. A region land asset is created by saving it from a new option in the Terrain tab of the estate floater. A region land asset is applied by dragging from inventory to a new special drop space in the Terrain tab. There MUST be SEVERAL confirmation boxes warning about the dangers of such an operation. When a region land asset is applied, it applies MOST of the settings in the terrain tab. Textures, elevations, terrain raw files, terrain visibility map; ignoring Water Height and Terrain Limits.

Why is this feature important to you? How would it benefit the community?

Because terrains appearances are randomly generated, and possibly the oldest system in SL worthy of a significant update.

Attachments

Original Jira Fields
Field Value
Issue BUG-230996
Summary Terrain Textures 2
Type New Feature Request
Priority Unset
Status Accepted
Resolution Accepted
Reporter NeoBokrug Elytis (neobokrug.elytis)
Created at 2021-07-20T16:25:24Z
Updated at 2023-05-18T22:28:11Z
{
  'Build Id': 'unset',
  'Business Unit': ['Platform'],
  'Date of First Response': '2021-07-21T07:50:14.189-0500',
  'How would you like the feature to work?': 'Good <insert time of day here>.  This is a looOooong feature request explaining in great detail how the feature would work.  Please make sure you have a drink and snack of your choice ready before proceeding.\r\n\r\n\tThis feature request is an update to improve how existing terrain textures are applied to regions.  Most importantly it ensures that all SL viewers have a uniform viewing experience, as well as providing the creator better control of how textures are applied to the terrain of the region.\r\n\t\r\n\tUsing a similar method to terrain height maps, this feature will determine which blend of textures are most visible at a given inworld coordinate on the terrain.  Then instead of using the current pseudo-random blend method to render textures on land, we define which textures are most visible at a given coordinate using a "texture visibility map".\r\n\r\n\tFor the terrain visibility map, this feature should use an image format that viewers already understand, and that can potentially be stored on the asset server to be applied at the region level via drag and drop, or converted into a unique asset type.  I suggest the format be a PNG, as it allows for the controlling 4 channels (texture sets) of visibility, while using lossless compression.  The four channels of RGBA would then define which terrain texture is most visible -- 0 being the lowest, and 255 being the highest.\t\r\n\r\n\tIt would be NICE if we upgraded from the existing 256x256px height .raw map that is on regions currently, to 512x512px.  Such an upgrade would allow defining which texture is most visible at increments of 0.5 meters on a region instead of every 1 meter.  The upgrade isn\'t a requirement, but would be nice.\t\r\n\t\r\n\tAnother feature improvement is to define the scale of repeats in meters.  Currently all terrains have a repeat of 12 meters, it would be nice to change this to something sane like 16 (because it divides into 256 nicely).\r\n\t\r\n\tIt would also be nice to allow the use of materials (speculars and normals) on terrain.  Speculars and normals follow lock-step with repeats and terrain visibility.  This would make for nice features such as wet land after a rain.  "Blending" of materials may be troublesome.\r\n\t\r\n\t----\t\r\n\t\r\n\tA couple new viewer side features would have to be created to support this, some which could borrow functionality from existing viewer features.\r\n\t\r\n\tThe first is a "terrain painter".  It could be a simplified version of the current terrain editor, but instead presenting an option for the four terrain textures as a pallet of "colors" (as defined by the existing estate options), a selection of brush sizes, brush shapes, and an option of brush strength.  Painting doesn\'t need to happen in real time server side, it can happen client side and send an update to the region (and then viewers) when a painting session is finished.  Or it could happen in real time with the same methods regions use now for terrain.\r\n\t\r\n\t"Painting" a texture "color" with a brush, would make it more visible (push it\'s value up), while making other "colors" at the same pixel coordinate less visible (push their values down).\r\n\t\r\n\t"Erasing" a texture "color" with a revert/erase feature, moves values closer to the region bake.\r\n\t\r\n\tWhile we\'re in there building for this feature I would suggest allowing a new single "pixel" brush size control, instead the current smallest 9x9 grid, and making the brush indicator more flush with the land instead of the hovering above it as it does now.\r\n\t\r\n\tWhen a viewer sees another region, it will have to download the Terrain Visibility Map in addition to the terrain height map.  From there it will use client side calculations to render the visibility for terrain textures, similar to the existing land application now; but without any randomized blending components.\r\n\r\n\tThe estate terrain floater will require a few small adjustments.  At the top it should have a drop-down selector or other UI element that selects the terrain version.  Selecting a terrain version will determine the layout of the floater.  Selecting Terrain Version 1, will use the classic floater.  Selecting version two will change options to the existing floater:\r\n\t\tRemove Terrain Elevation Ranges.\r\n\t\tAdd Upload and Download Terrain Visibility Maps.\r\n\t\tAdd Bake Terrain Visibility.\r\n\t\tAdd Specular and Normal Maps for terrain textures.\r\n\t\r\n\t----\r\n\t\r\n\tServer Side it would just have to store the following information at the region level:\r\n\t\tTerrain Version:\t\tTells the viewer which method of terrain rendering it should use.  (1 or 2)\r\n\t\t\t1 is Classic\r\n\t\t\t2 is This Feature\r\n\r\n\t\tTerrain Scale:\t\t\tUser defined in meters.  Sane limitations?, 2-128?  Defaults to 12\r\n\t\tVisibility Map:\t\t\tA texture UUID of the current map.\r\n\t\tBaked visibility map:\tA texture UUID of the bake.\r\n\t\t\r\n\t----\r\n\tAdditional Feature Creep:\r\n\t\tAllow residents to change the terrain visibility of their own parcels using ONLY the estate defined textures, in the same way that residents can edit their terrain now.  If this feature is added, make it an additional estate level option whether or not land owners could change the painted land.\r\n\r\n\t\tNew Region Land Asset:  Create a specific type of asset that only estate managers and owners can apply to a region.  This asset should function like any other SL asset with regards to permissions, and being sold on the Market Place.  A region land asset is created by saving it from a new option in the Terrain tab of the estate floater.  A region land asset is applied by dragging from inventory to a new special drop space in the Terrain tab.  There MUST be SEVERAL confirmation boxes warning about the dangers of such an operation.  When a region land asset is applied, it applies MOST of the settings in the terrain tab.  Textures, elevations, terrain raw files, terrain visibility map; ignoring Water Height and Terrain Limits. ',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'Target Viewer Version': 'viewer-development',
  'Why is this feature important to you? How would it benefit the community?': 'Blah, formatting edits are forthcoming.',
}
@sl-service-account
Copy link
Author

Vir Linden commented at 2021-07-21T12:50:14Z

Pulling this in as possible work for the proposed texture update project. Certainly making the blending deterministic and consistent across viewers would be an important goal there, and giving more control of blending may also make sense.

@sl-service-account
Copy link
Author

JIRAUSER339827 commented at 2023-05-18T22:28:12Z

I like the idea of changing the terrain repeats to be a whole multiple of the terrain. Might be doable for PBR terrain only, for the PBR terrain project.

https://github.com/orgs/secondlife/projects/17/views/1

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant