Using Custom Material inside of a BJS build?

Questions
1

import { CustomMaterial } from “…/…/materialsLibrary/src/custom/customMaterial”;

Gives me the error that its outside the rootDir. What would be the method of getting that to import to work inside the src folder of bjs? Its prolly not something I can do and I am assuming I will have to find a different way to accomplish what I want.

2

@sebavan if you get some time. :slight_smile:

3

ohhhhh, you should not do that :slight_smile: and the error is intented to happen.

We do not want any custom materials in the core lib. They are dedicated to be used aside core not from within.

May I ask what the use case is ?

4

I wanted to be a tricky boi and get all the spriteMap stuff working with all our Standard Material functionality so we could have lighting effects and other things worked out that would match the 3d stuff. I guess the convention then will be to make a SpriteMapMaterial that is an extension of the standard material, but is more specific for that task then the CustomMaterial.

Honestly it would be ideal if the StandardMaterial just had all the injection methods the CustomMaterial has.

5

If you need to extend it it might be done through define or other techniques. We should not need internally to rely on custom material. Actually, custom material is a way to customize from outside the lib but if you change the lib itself you have all the freedom to adapt at the source level.

6

I see that it has #define CUSTOM_#### sections. Is there a way to tap into them? What other techniques could I deploy?

Ideally I dont want to have to replicate all the stuff from the lighting model, which is ezpz on the shader side but then having to create the class controller for it as well is kinda a time constraint I dont want to take on right now.

7

Gives me the error that its outside the rootDir

Possible workarounds without modifying BJS code:

  1. symlink materialsLibrary inside src (not sure about Windows though)
  2. if using Webpack, Resolve | webpack
8

:)) i Guess that can be replaced by standard material

9

As long as the code is meant to be contributed, we can not have a dependency from core to materials library.

Also internally relying on CUSTOM_ defeats the point as then users will not have this freedom anymore.

Why not simply adding either another replacement tag like SPRITE_… ? or integrate a #ifdef SPRITE and inherit from the standardMaterial in the code ?

1 Like
10

Smart man, that might be the key.