Feedback on 'The inspector'

Just a quick feedback on my finding in the inspector:
For #rendering pipelines, for #ssao, for #radius:
The inspector value field could do with a higher number of decimals. I cannot get the value of radius after 3 decimals.

Capture d’écran 2021-01-11 à 11.47.05

Side-note: I cannot retrieve any changes to i.e. my rendering pipelines with the actual record and export to json feature. The replacement of the (hear me crying;) r.i.p. pseudo-code method. Though, in this particular case, the ‘pseudo-code’ method did also not return all of the changes.
I guess this is where it would be important to be able to enter and retrieve the correct value (and the correct name/access method).
I noticed you did some changes in late summer to let us finally enter values where sliders are used (i.e. rotation). I think that since we are mostly working with values, it would be interesting to be able to input and retrieve the correct value every time. I believe at this moment there are still (a number of) places where I cannot enter or retrieve the exact value.

The ability to save the changes in the scene after editing it in the Inspector is really very needful function.

Hi there! It is definitely possible to increase the precision on these input boxes. Though want to double check with @PatrickRyan for the go ahead. As for the final line, I’m not quiet sure what you mean. Could you give an example and I can take a look :slight_smile:

Yes, I have gathered these on the way (and as I said, some have been fixed already:) Also some did strike me more than others. I will take some time to go through again and will try summarize my findings… I’ll be back.
Have a great day,

1 Like

Looking forward to it! Feel free to @ me directly when you post.

It is supported :slight_smile:
Applying Delta Changes To A Scene | Babylon.js Documentation

1 Like

Maybe I was doing something wrong, but after some changes of the scene (clearColor etc) with the Inspector at Playground I could not save anything but empty diff.json file - like this {} .

If you can repro I will gladly have a look :slight_smile:

This is all what I’ve got in the diff.json:
{}

Still sometimes I was lucky to get the clearColor in .json file (mainly when camera position changed, but not always).

Another problem is that you cannot upload delta file in Opera browser (the screen is just covering with the overlay).

Yes, I can recall that some #scene inputs, but also activating (enabling/disabling) things such as in #rendering pipeline and a number of interactions here or there are simply not recorded. As I committed to make a quick review of the inspector, I will also try some recording same time. I’ll let you know if I hit anything in particular…

Edit: There are limitations mentioned and I also agree that these limitations have a meaning. May be the example of the above #scene, #clear color is not the best example… as I said I recall others (more troublesome), may be also related to (as mentioned in the doc #limitations) " *…It will not record large state changes "… here ‘large’ would need to be defined;)… and I recall it also takes ‘intermediary’ steps (i.e. when setting gradients on particles, making the output barely useable/readable…)… As I said, I will check back and let you know if I have an interesting enough to mention feedback on this.
Have a great day,

Edit2: it looks like the part of my comment for intermediate steps when using the sliders for setting gradients for particles can (now) be disregarded. It seems to work perfectly :smiley:

I will. Just give me a couple more days. I shall make a batch together with my overall (high level) suggestion of changes so yours can decide if worth working on. If so, I’m also ready to give a hand going through the ‘entire’ process…

Edit: I need more time because I just got the answers I was seeking for finally implementing post-process and graphic settings in my small demo scene - with the invaluable input from @Evgeni_Popov and at @labris . You Guys are Legend :smiley:

1 Like

Good Day Everyone,
@msDestiny14 , @labris,
Thought I would quickly share this for a start:

  1. There is something with the scene color in the inspector (not about the recording).

COLOR VALUES ARE INCORRECT ACCORDING TO COLOR SPACE IN

scene#clear color# for #r#g#b

incorrect values for rgb show a 0 to 0.255 range instead of 0 to 255.
Edit: – or – It should be somehow stated that these values are not the RGB values as above. I’m not sure how to explain this but there is something weird between selecting from the colorpick and the way we get the value… may be it’s just me on this one.

Capture d’écran 2021-01-20 à 10.38.57

Edit 2 (oops;)
Now I think I just found what was disturbing me. It’s about ‘consistency’.
Colors with the name of r, g, b use the BJS values of 0 to 1. And R, G, B is displaying RGB values. That’s fine. Now, look at #rotation. Here we do not have the same format. The values are shown in gradients. They are named x, y, z (as opposed to XYZ) but those ones are not in ‘standard’ BJS format.

Capture d’écran 2021-01-20 à 11.27.31

Other finding →
2) Still cannot enter values at some places where sliders are used. i.e.:

particles#colors#color gradients

Capture d’écran 2021-01-20 à 10.52.50

Other finding →
3) There are places where the ‘header description’ does not correspond to the ‘function’ (name,…)
Although it can be discussed (yours can discuss this around a coffee;) whether it would be useful/appropriate to somehow ‘link’ the (API) name to display straight in the inspector (or as a helper)… beyond that, I found some troublesome ‘translations’ to match the API (or constructor) names.
i.e.: On #rendering pipelines, for #depth, for #distance, for #distorsion. Ask any photographer and he will tell you that focus depth or distance is not at all the same as distorsion or edge distorsion.

Now, 2 things here: First, obviously, you Guys did a hell of a job since last summer. Many parts have already been updated and improved and the ‘Inspector’ or ‘Scene Explorer’ (as it is called and as I use to use it - as a support tool) is becoming… something more… something even better:)

Second, this exercise I started (and I’m willing to do/help with) is not exactly a fun piece;) So, I’d rather let you Guys discuss this from the above and next, if you feel like this could be helpful/important, let me know and I will go the extra mile for this objective…
Have a great day,

Color values in Babylon.js are in range 0 to 1 Color3 | Babylon.js Documentation

Where are you trying to enter values. The slider gives the point during the particle lifetime to change color not a color value. Click on a color to change it.

image

See Changing Particle Properties Over Time | Babylon.js Documentation

EDIT I think I now understand. You mean there is nowhere to enter values. Is this related to

Personally I don’t see the reason to enter a value as well as use a slider or to display more decimal places. The inspector gives you a quick way of seeing and changing value to see overall effect. If you then want to see more precise values the use the console, to enter more precise values do it in the code.

Yes, this is where I cannot enter a value. And also yes for the decimals, though I do agree to your conclusion (and I’m actually doing this and have always been doing this;)… I still find it weird to display a value of 0.000 when it is not. Better display no value at all if the slider is just for ‘evaluation’.

Let me just give you another example about inputs and decimals to better highlight my point:
For alpha index, I can see and retrieve something like this:
1.7976931348623157e+308

Edit: However, the inspector lets me change it, but I can only change it to (something like) 1.62.
A value I can now better understand thanks to help of some of the amazing contributors:) Still not sure why we can make this sort of input (or who uses it)…

… Now, knowing that I can do this in ‘the inspector’, how am I supposed to understand the format and value of ‘0.000’ (incomplete) in another part of the tool?

This is a number in E-notation it means 1.7976931348623157 x 10308 and is so close to 0 as not to matter.

Perhaps in some cases the code to format the displayed value is not applied or cannot deal with e-notation. It would make sense for some form of consistency to display valued to 2 or 3 dec places.

Some of the design decisions depend on available space and whether it gives room on a line for a value display as well as a slider and other linked properties.

For a simple start I think I can add a input value onto the gradient slider.

1 Like

Well, again, these are simple suggestions. Since I spent some time (1 year) to go through the entire process of evaluation, I thought I could here or there go the extra mile and let yours know about my ‘experience’. As I stated a number of time in this forum, I do not have ‘expectations’ with BJS at this level.
Though I’m sure many people now start to have ‘expectations’ at many levels;)
My only expectations with BJS (and my only wish) is that you Guys keep with your promise (and keep with your pillars) despite the ‘disturbances’ that are likely to increase.
As for ‘the inspector’, I believe I can sense that this could eventually become a topic creating ‘friction’.
Between those who want to keep with its original meaning and name of an ‘explorer’ or ‘inspector’ (a support tool) and those who’d eventually want…well, something else like a ‘toolset’.
Personally, I (willingly) did the effort to absolutely not use ‘the Inspector’ at all during the first 3-months of my apprenticeship of BJS. I have always done that. I believe the only thing you need to code is a doc and a notepad/text editor. So I had no ‘expectations’ when I first started the tool. I can remember that the first thing that raised my interest (and participated to an increase in my CX) was to have all the hierarchy and names of my scene. This helps a lot detecting simple copy/paste errors when creating the scene. Second was to be able to make inputs for scale,position,rotation of meshes. At this time, I was unhappy not being able to enter a value in ‘rotation’. This has been changed later on (and thanks for this change, it really helps).
Overall, yours must have gone already through a number of times, because this is actually VERY CLEAN, again in my opinion. Not sure if it would be necessary to go through once more just right now…

1 Like

Hope nothing I wrote let you think this was the case. You have had a positive reply from @msDestiny14 about some changes and I whilst stated my opinion it is just my opinion and I agreed with you about consistency.

What gave you this sense of possible friction. Could it be a communication issue?

I can assure you it is not me. I have no point of ‘friction’ with the inspector (or with BJS). But if I was part of the core team, I guess I would want to keep an eye on this part.