windows 10
Chrome / Edge / Firefox last version
GTX960
The other examples are working correctly?
The same problem
I donât have a clue what is the issue here⌠I need to test on different HW.
@sebavan @Evgeni_Popov @Deltakosh @carolhmj
Hello!
So guys, it seems itâs time to create a PR but have a few more questions beforehand.
- Will
GreasedLineBuilder
be a part oflinesBuilder.ts
or should I keep it in a different source file? - You can create a
GreasedLine
class without using the builder function but you need to provide the inputs converted/normalized. There are functions for these operations and are part of the builder for now. The question is should I expose them fromGreasedLineBuilder
like this:
export const GreasedLineBuilder = {
CreateGreasedLine,
Color3toUint8,
ConvertPoints,
NormalizeColorTable,
NormalizeWidthTable,
TextureFromColors,
};
or should the GreasedLineBuilder
be clean:
export const GreasedLineBuilder = {
CreateGreasedLine,
};
and should I create a GreasedLineBuilderTools
objects with these functions or maybe GreasedLineBuilder.Tools
:
export const GreasedLineBuilder = {
CreateGreasedLine,
Tools: {
Color3toUint8,
ConvertPoints,
NormalizeColorTable,
NormalizeWidthTable,
TextureFromColors
}
};
Iâve created some other tools functions as getLineLength, divideLine, getSubLines, segmentizeLine, circle, grid, geometryToLines, ...
(functions names are subject to change before PR) These are not required to use but are very useful when dealing with GreasedLine
. Whatâs you recommendtion, where to put these functions? Is GreasedLineBuilder.Tools
a good choice? I am not 100% because these functions can be used with the existing line functions as well.
- Interfaces. Should I avoid them and put the definition in the method like seen in the existing
CreateDashedLines
function? (options)
export function CreateDashedLines(
name: string,
options: { points: Vector3[]; dashSize?: number; gapSize?: number; dashNb?: number; updatable?: boolean; instance?: LinesMesh; useVertexAlpha?: boolean; material?: Material },
scene: Nullable<Scene> = null
): LinesMesh {
- I use a few
enum
s, should I switch to const values on the object?
Thank you!
Let s summon @RaananW to see what best fit to be ready with the ESM work he is planning without introducing to much inconsistencies with what we have in the framework
Do you have a playground for these examples?
Yep, Why not
Sry, no playground yet, only source code of the demo page.
Itâs really simple, you just load the mesh, call the meshesToLines
utility function, define the colors, widths and create the lines:
const loaded = await SceneLoader.AppendAsync('/models/', 'monkey.glb');
const root = loaded.meshes[0];
root.setEnabled(false);
const meshes = root.getChildMeshes(false);
const points = meshesToLines(meshes)
//
const colors1 = [new Color3(1, 0, 0), new Color3(0, 0, 1), new Color3(0, 1, 0), new Color3(1, 1, 0)];
const widths1 = [20, 0, 0, 2, 0, 10];
const mesh = GreasedLineBuilder.CreateGreasedLine(
'lines',
{
points,
widths: widths1,
widthsDistribution: WidthsDistribution.Repeat,
colors: colors1,
useColors: true,
colorDistribution: ColorDistribution.Repeat,
},
scene
);
Demo page:
src/pages/demos/GeometryDrawPage.vue
Utility function (locatiion of the util functions is probably going to change and will be placed in GreasedLineBuilder.ts):
Please note the repo is still under development and some of the local changes were not pushed yet.
Oh, great questions. And sorry for answering so late.
In general - anything you export in a file that is exported from an ĂŹndex.ts` file will automatically be a part of the BABYLON namespace (unless you change its name). Of course, that includes files that are referenced from other files.
The reason we have the builders is backwards compatibility. There is actually no true need in the Builder structure. We also stopped using other namespaces and keep everything as flat as possible.
Having said that - the architecture is not yet ready to work as you expect, without exporting at least a single object (i.e. the LineBuilder map).
Long story short:
- For the time being, stay with the const builder that holds everything
- Try to avoid exporting to the global namespace as much as possible. This is a mistake I have made in some cases. Anything we expose to the global namespace will stay backwards-compatible.
- Use interfaces where it makes sense. I donât see a reason to add an interface to the CreateLine function. Follow what we did with the other Create methods (i.e. - options are also not an interface). This is something we can improve later.
- Try to avoid enums as much as possible and use constants as much as you can. They keep the package size smaller and are faster.
Let me know if I missed something! And please tag me on the PR
@RaananW thank you and no worries for the late answer I am 1000% busy these days⌠I can get back to the PR this weekend.
Thanks!
R.
After copying my sources from my standalone project to the Babylon.js repo Next time it will be wiser to start to code in the repo directly to avoid unresolved imports and to deal with a different ecosystem
I appear to get the same issue as @DWork (post), using any browser (openSUSE, GTX970).
The pg from this post however seems to render fine, whereas the newer version from Babylon App has the same blurred/semi-opaque look.
Hello!
Can you help me to deal with this issue please?
I am using materials/PBRCustomMaterial
as the base class for my core/GreasedLinePBRMaterial
.
packages/dev/core/src/Materials/PBR/pbrGreasedLineMaterial.ts(5,35): error TS6059: File '/Users/roland/code/Babylon.js/packages/dev/materials/src/custom/pbrCustomMaterial.ts' is not under 'rootDir' '/Users/roland/code/Babylon.js/packages/dev/core/src'. 'rootDir' is expected to contain all source files.
I get whatâs the problem here, I have some ideas how to solve it but I donât know whatâs the correct solution.
Thank you!
We can not use PBRCustomMaterial in core
We should probably try to migrate into a material plugin if possible or embed in the main code if not ?
Are you going to elaborate on this question and will you let me know how to proceed?
If your code requires code from the materials package, it will need to be added to the materials package. Core has no dependencies. Materials has core as dependency.
Add your material there. It can be tested in the local playground, as the package is being generated and used in both local and public playground.
@sebavan - think the base class needs to be in core?