ReflectionProbe.renderList.add() using ES6/Typescript

Hey guys, and I am looking through an example which uses the ReflectionProbe as follows:

var attachReflectionProbe = function (scene, root, others) {
var probe = new BABYLON.ReflectionProbe(root+“ReflectionProbe”, 128, scene, true);
for (var index = 0; index < others.length; index++) {
probe.renderList.push(others[index]);
};
root.material.reflectionTexture = probe.cubeTexture;
root.material.disableLighting = true;
probe.attachToMesh(root);
}

For use with typescript and ES6 I have converted the code to the following:

attachReflectionProbe (scene:Scene, root: Mesh, others: Mesh) {
var probe = new ReflectionProbe(root+“ReflectionProbe”, 128, scene, true);
for (var index = 0; index < others.length; index++) {
// The following line throws errors on compile
probe.renderList.push(others[index]);
};
(root.material as StandardMaterial).reflectionTexture = probe.cubeTexture;
(root.material as StandardMaterial).disableLighting = true;
probe.attachToMesh(root);
}

I am using strict checking and it throws the following error:
// The line number associated with the error is commented above
TS2531: Object is possibly ‘null’.

How can I access the list to add new meshes to it? It looks like the renderList parameter is read-only, and the RenderTargetTexture which hosts the value on ReflectionProbe is also inaccessible.

Thanks for any help,
r

A simple check for the object seems to have solved the problem.

if (probe.renderList) {
// put in work
}

r

Strange, it works here without checking first:

renderList is not declared as nullable…

The getter signature is:

public get renderList(): Nullable<AbstractMesh[]>

Mainly because the RenderTargetTexture is Nullable as well. checking that it is not null is the safest way to go here :slight_smile:

Ah, strange (bis), the PG does not show it’s nullable:

image

Interesting!

This is from the latest babylon.d.ts:

image

Need to see why it does that

it seems Nullable is completely ignored on the playground. For example:

Which should return Nullable

Before digging in - anyone has an idea why it happens?

no idea…

strictNullCheck might not be turned on ??? just an idea though :slight_smile: