PeapBoy

Members
  • Content Count

    68
  • Joined

  • Last visited

About PeapBoy

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi, Sorry, in holidays 😅 You can find the PR here: https://github.com/BabylonJS/Babylon.js/pull/4839
  2. Well, I succeeded in compiling the code. I needed to add all the WebGL2 constants in babylon.webgl2.ts. There is still a lot I don't know about how works BJS 😅
  3. Yes, just adding the constants and updating the _getRGBABufferInternalSizedFormat(), _getInternalFormat() and _getWebGLTextureType() functions should definitely be enough to create any texture you want with BABYLON.RawTexture or BABYLON.RawCubeTexture ! 😊
  4. Hi ! Actually it's not a lot of work of adding a few constants but thanks haha Yes, principally Apple devices still don't support WebGL2 (so annoying...). But in such cases, BabylonJS already falls back on UNSIGNED_BYTE texture type. I admit I don't really get what you're trying to explain x) I don't really like the WebGL2Texture. I don't think the user should manage whether the devices support or not WebGL2, BabylonJS should do it as it already does, inside the Texture classes that already exist. Because it's one of the annoying task I expect Babylonjs to do for me. And I just discovered that BabylonJS provides RawTexture and RawCubeTexture that exactly do what you seem to expect from WebGL2Texture 😁 Adding the constants. Nothing changes. Every function/constructor that already wait for a format and a type parameter should work as usual.
  5. Uh. Of course they exist 😠 Sorry but what should I do with gulp so it doesn't fail compiling because of the new WebGL2 constants ? I saw this in the code: // Constants this._gl.HALF_FLOAT_OES = 0x8D61; // Half floating-point type (16-bit). if (this._gl.RGBA16F !== 0x881A) { this._gl.RGBA16F = 0x881A; // RGBA 16-bit floating-point color-renderable internal sized format. } if (this._gl.RGBA32F !== 0x8814) { this._gl.RGBA32F = 0x8814; // RGBA 32-bit floating-point color-renderable internal sized format. } if (this._gl.DEPTH24_STENCIL8 !== 35056) { this._gl.DEPTH24_STENCIL8 = 35056; } How is it possible that we need to rewrite some constants !?
  6. Hi! 1. Noted. 2. So UNSIGNED_INT won't refer to UNSIGNED_INT and we'll invent UNSIGNED_INTEGER (or anything else) that actually will refer to UNSIGNED_INT, I really hate backwards compatibility 😅 3. It's fine for me, the impacted combinations that will not be possible don't affect my needs and I think they're very unsual. 4. Because RG is the good naming. It's gl.RED, gl.RG, GL.RGB and gl.RGBA. It's absolutely not important though, just my will to add a constant with the good naming, I didn't plan to remove gl.R at all, just a new one (RED) referring to the same as R. 5. My bad, you're right, UNSIGNED_INT is only referring to UNSIGNED_BYTE, you directly call gl.UNSIGNED_INT for depth textures and drawElements() functions. So I suggest UNSIGNED_INTEGER as a new name for UNSIGNED_INT but I think this should be strongly stated in the docs. Ok, thank you, understood!
  7. Hello ! As I'm currently playing with some unsigned integer textures, I would love to see BabylonJS support them. I'll do a PR as soon as possible, adding some (all ?) constants about internal formats (for instance Engine.TEXTUREFORMAT_RGBA_INTEGER) and texture types (for instance Engine.TEXTURETYPE_UNSIGNED_SHORT), and updating the function to retrieve the internal sized format in order to be able to return new values as gl.RGBA16UI. Does it seem ok for you ? Moreover, we're still using Engine.TEXTURETYPE_UNSIGNED_INT to refer to both gl.UNSIGNED_INT (only available for depth textures in WebGL 1) and gl.UNSIGNED_BYTE texture types. I think we need to do a breaking change because gl.UNSIGNED_INT is now a valid texture type for unsigned integer textures in WebGL2 like RGBA32UI textures. Valid combinations of internal format, type and internal size format are listed here in table 3.2. Color-renderable and texture-filterable formats are listed here in table 3.13. This info is also gathered here. And this is a bit less exhaustive in WebGL 2 Specs. [EDIT] With WebGL2, specify the internal sized format will be necessary as some combinations of format and type don't lead to a unique internal sized format. For this purpose, we'll need to add internal sized formats as constants in BABYLON.Engine and we won't lean on _getRGBABufferInternalSizedFormat() function anymore. However, only a few combinations fail to give a unique result: - RGBA format + UNSIGNED_BYTE type - RGBA format + UNSIGNED_INT_2_10_10_10_REV type - RGBA format + FLOAT type - RGB format + UNSIGNED_BYTE type - RGB format + HALF_FLOAT type - RGB format + FLOAT type - RG format + FLOAT type - RED format + FLOAT type So we could just ignore them and return a default value in these cases, for now. [EDIT 2] Current type constants: private static _TEXTURETYPE_UNSIGNED_INT = 0; private static _TEXTURETYPE_FLOAT = 1; private static _TEXTURETYPE_HALF_FLOAT = 2; Suggested new type constants: private static _TEXTURETYPE_BYTE = 0; private static _TEXTURETYPE_UNSIGNED_BYTE = 1; private static _TEXTURETYPE_SHORT = 2; private static _TEXTURETYPE_UNSIGNED_SHORT = 3; private static _TEXTURETYPE_INT = 4; private static _TEXTURETYPE_UNSIGNED_INT = 5; private static _TEXTURETYPE_FLOAT = 6; private static _TEXTURETYPE_HALF_FLOAT = 7; private static _TEXTURETYPE_UNSIGNED_SHORT_4_4_4_4 = 8; private static _TEXTURETYPE_UNSIGNED_SHORT_5_5_5_1 = 9; private static _TEXTURETYPE_UNSIGNED_SHORT_5_6_5 = 10; private static _TEXTURETYPE_UNSIGNED_INT_2_10_10_10_REV = 11; private static _TEXTURETYPE_UNSIGNED_INT_24_8 = 12; private static _TEXTURETYPE_UNSIGNED_INT_10F_11F_11F_REV = 13; private static _TEXTURETYPE_UNSIGNED_INT_5_9_9_9_REV = 14; private static _TEXTURETYPE_FLOAT_32_UNSIGNED_INT_24_8_REV = 15; NOTE 1: As every user should use the public constants and not directly the private numbers the constants are bound to, we should be allowed to modify the order (FLOAT will be defined by 6 instead of 1 for instance). If you do not want to change the order of the three first constants already defined, just say it. NOTE 2: UNSIGNED_INT will not refer to UNSIGNED_BYTE anymore. Breaking change. [EDIT 3] Current format constants: private static _TEXTUREFORMAT_ALPHA = 0; private static _TEXTUREFORMAT_LUMINANCE = 1; private static _TEXTUREFORMAT_LUMINANCE_ALPHA = 2; private static _TEXTUREFORMAT_RGB = 4; private static _TEXTUREFORMAT_RGBA = 5; private static _TEXTUREFORMAT_R = 6; private static _TEXTUREFORMAT_RG = 7; NOTE 1: No 3 ? Did I miss something ? NOTE 2 : I personally guess TEXTUREFORMAT_R is not a good idea for 3 reasons: - It's confusing for people already used to WebGL who know it's gl.RED and not gl.R - It doesn't seem really instructive for beginners who will think R is the good naming - Beginners generally don't play with texture formats and types That's why I suggest to create and use TEXTUREFORMAT_RED in the future. And keep TEXTUREFORMAT_R for retrocompatibility. But once again, it's only a suggestion. Suggested new format constants: private static _TEXTUREFORMAT_ALPHA = 0; private static _TEXTUREFORMAT_LUMINANCE = 1; private static _TEXTUREFORMAT_LUMINANCE_ALPHA = 2; private static _TEXTUREFORMAT_RED = 3; private static _TEXTUREFORMAT_R = 3; private static _TEXTUREFORMAT_RG = 4; private static _TEXTUREFORMAT_RGB = 5; private static _TEXTUREFORMAT_RGBA = 6; private static _TEXTUREFORMAT_RED_INTEGER = 7; private static _TEXTUREFORMAT_R_INTEGER = 7; private static _TEXTUREFORMAT_RG_INTEGER = 8; private static _TEXTUREFORMAT_RGB_INTEGER = 9; private static _TEXTUREFORMAT_RGBA_INTEGER = 10; NOTE 1: Once again, we should be allowed to change the order of the first constants as nobody should use the private numbers directly.
  8. Hi Nabroski ! Thanks for the precious info. Render to a RGB16F texture was possible in WebGL1 with the EXT_color_buffer_half_float extension but isn't possible in WebGL2 anymore as this extension doesn't exist anymore. With the EXT_color_buffer_float extension available with WebGL2 though, it's possible to render to R16F, RG16F, RGBA16F, R32F, RG32F, RGBA32F and R11F_G11F_B10F texture. I didn't know the existence of the function uintBitsToFloat(), very handy ! Now, I should pay attention at the precision loss and at the performance gain of using RGB8 texture (not necessarily faster to read RGB textures).
  9. Hi ! As we can see here, RGB format is not required by Opengl specifications (and therefore, by WebGL). That means it's supported for textures but not always for renderbuffers. That's why it worked in my PG which didn't render to a target. I'm sorry for wasting your time, I didn't know this. That's just not possible for now. 🙂
  10. My bad, you're right, I'll come back tomorrow with a new PG if it works 🙂
  11. Hello ! As WebGL2 comes with new texture formats, I decided to play a bit with them, and it seems to work well in pure WebGL2: https://playground.babylonjs.com/#RBQYSP (If it prints red, that means the RGB texture did work 🙂) I saw texture format has been added to createRenderTargetTexture function so I wanted to try it out. But whatever I do, I never achieve to create a RGB Render Target Texture. 😥 This code works to create a RGBA RenderTarget: https://playground.babylonjs.com/#RBQYSP#5 This code fails to create a RGB RenderTarget: https://playground.babylonjs.com/#RBQYSP#6 Framebuffer is incomplete. I already pulled the last version of BJS and added gl.pixelStorei(gl.UNPACK_ALIGNMENT, 1) everywhere but it doesn't help much. I'm struggling with this, I don't understand where something is different from the pure WebGL2 version. I verified InternalSizedFormat, InternalFormat and TextureType and they're OK. If anybody has an idea... Thanks in advance 😊 PeapBoy
  12. Of course Thank you very much and sorry for the stupid question
  13. Hello, No bug, no issue today ! I was just wondering about the choice of linking materialDefines to subMeshes, rather than directly on materials themselves. Does that mean that two subMeshes could have the same material, but different defines ? As the material updates the defines depending on its own properties (not the properties of the subMesh), I can hardly see how it's possible. I would love to see an example of this if you have one. I mean, I'm missing something. I'm quite sure this choice has been made for a good reason. But I don't get why. Thanks for your help !
  14. PeapBoy

    Render color outside [0..1] range

    Done https://github.com/BabylonJS/Babylon.js/pull/3715
  15. Woohoo! Doors of compiling are open again!