Bandor Beningborough

This is an old thread, but I saw some comments in here that made me want to reply. As a builder, I can tell you that working with PBR is fantastic. Having one file to upload and use for all my texturing on object. Just dragging 1 thing on and being done, versus having to manually put 3 materials. But, providing a FALLBACK non-PBR material is a pain. It means we have to support both PBR and non-PBR in everything we make, and that is a horror story. There are massive challenges for using both. Like, you can't see the non-PBR textures in a PBR viewer once PBR materials are added. Like, having to have 2 different scripts for texture changers.. one for PBR and one for non-PBR because they use different prim parameters and functions. If SL wants us to have "fallback" textures, why not just make the feature work that way??? Why not just have SL automatically assign the base color image as the diffuse image. It works. In fact, that's how I do a lot of my non-PBR textures now is I just copy the base color image and the normal and use them in the Blinn-phong. I don't have a specular that way, but frankly I don't use them that much. If I do its usually solid white. If applying a PBR material also set the DIFFUSE and NORMAL... we would not have to manage both.

So, how about expanding on the idea of a BRAND and allow merchants to have multiple named Brands within their single merchant account? So, each Brand could have its own banner and landing page. When we upload products, one of the fields in the edit panel would be to select (and add/delete) the brand for the product. In the data, it would be one additional field per product. We could then filter our reports by that column. In listings, the link that currently shows "Store Name" by "Store owner Name" could be changed to BRAND NAME instead. When people click on the brand name, it takes them to the brand landing page. Having worked in eCommerce development since the 90's I don't see this as a massive change. Merchants with multiple "brands" could even have a Landing Page for the primary parent entity. In most eCommerce systems that I've worked with a "Brand" is just another kind of "category". And, just like Categories have a hierarchy, brands can too. So, say you start a new merchant account under the name of "My Cool Brands", and then define 3 brands "My Cool Clothes", "My Cool Furniture" and "My Cool Prefabs". Products would be linked to both "categories" and "brands". Every merchant would have 1 default brand but could add multiple Sub-brands. So, yes, it would require code changes, but they do not seem that significant. Core functionality would not change. Sales, reports, transactions, would all take place exactly as today. The brand is really irrelevant to them. Brand is simply a categorization issue. So, changes would be needed in: Brand Management (new): Add, display, modify, delete brands. Product Edit Page: (for adding and editing products) Add a field to select a brand for the product (and potentially link to the Brand Management functions). Default Brand Landing Page: the default brand landing page would be the current landing page for the merchant. If the merchant has one or more brands, display a filter control for brand. Anywhere the BRAND name is shown, make it a hot link that takes the user to the Specific Brand Landing Page. Technically, from an implementation perspective, there would only be one landing page, but based on the parameters passed and the brand hierarchy, it would display the appropriate Banner and have the appropriate brand filters. For example, a link to https://marketplace.secondlife.com/stores/<store number> would generate the default store listing. A link to https://marketplace.secondlife.com/stores/<store number>?brand=<brandID> would generate the specific brand landing page Product Listing Page: Change the store name/link to a Brand name/Link if the product is in a brand Product Detail Page: Change the store name/link to a Brand Name/Link if the product is in a brand Reporting: Add a column for Brand and allow sorting by brand There may be a few other areas where changes would be needed, but this doesn't have to be SUPER ROBUST and FULLY FEATURED. It would be nice, but its not necessary. Anyway, just some thoughts... As far as Casper and other systems, they would be unaffected. As far as they would know, a product is a product.; a sale is a sale. Hover, they COULD add BRAND if they wanted to offer an enhanced functionality. For me, the importance is the FRONT END, ie what the customer experience is. I can deal with the back end and figure it out. I just would really like to have the ability to have separate brands. Bandor