Nockawa

Members
  • Content count

    603
  • Joined

  • Last visited

  • Days Won

    26

Nockawa last won the day on January 13

Nockawa had the most liked content!

4 Followers

About Nockawa

  • Rank
    Advanced Member
  • Birthday 06/19/1976

Contact Methods

  • Website URL
    http://www.loicbaumann.fr
  • Twitter
    loicbaumann

Profile Information

  • Gender
    Male
  • Location
    Paris Area
  • Interests
    Programming, Lego Technic

Recent Profile Visitors

1,246 profile views
  1. Well, this is weird... I can reproduce the issue with this PG http://babylonjs-playground.com/#2AVSFH#213 But when I run the exact same code on the exact same browser locally it doesn't bug! I don't think I have a more recent version of BJS sources locally, I can see clearly that the hardware scaling make the HTML Canvas flick, but the render stays the same, with the same pixel size... @Deltakosh do you have an idea?
  2. If I perform the rotation/scale before the positioning you won't get this result: the position of the rect will be changed in order for it to match the "h: left, v:center" alignment. You will always see the rect in the canvas and its position will always be left/center. It will probably spin as if its origin would be 0.5,0.5 but I'm not even sure of that, I think it'll be spinning differently, because I'll change the position of the rect. Currently I'm using actualSize to perform the positioning, but if I compute the rotation/scale before, I will have to use the resulted boundingRectangle to do the positioning, I don't think how I could do this differently.
  3. @royibernthal Look at this PG: http://babylonjs-playground.com/#272WI1#81 Now imagine that we set a marginAlign of "h: left, v:center", I rotation is made before the positioning, I think the result will be the rect spining weirdly, but still sticking the left border and being centered vertically. My feeling about this is it's not really what the user would want. but I don't really know, I need the feedback of as many people as possible
  4. This post might interest @royibernthal @MasterK @TMTH and @adam I think. Most of you have reported issues with using scale/origin and the positioning engine, I've looked to these issues and then to my code and I finally ended up wondering if what I'm currently doing is the right way and also if there's a right way to do things. Ok, let's be a bit clearer, for now, here's how things work: You create a Prim, set its margin, marginAlignment, origin, scale, rotation During the pre rendering phase I compute the position/size of this prim based on the margin and marginAlignment properties Then, I compute the globalTransformation matrix using the position computed by the positioning engine, the rotation, the scale (both considering the origin). The thing is the rotation/scale/origin are processed after the positioning engine. So let's take some example to illustrate the consequences of that If you set a scale of 0.5 and align center the prim the result will be as expected if the prim's origin is 0.5,0.5, because the scale shrink the prim at its center so the align center is still good because there's the same amount of pixel shrunk to the left and right (let's just consider the X axis, the same apply to the Y). If the origin is 0,0, then the Prim shrink related to its bottom/left corner, so all the pixels that are shrunk will be on the right of the prim, hence resulting to a bad align center. If you set the scale to 0.5 and align left, then the result will be good if you set an origin of 0,0 and it will be bad for other values (0.5,0.5, 1,0, etc.), if you think about it a bit, you will understand why and realize it makes sense considering the current implementation of things. Now I could solve this issue by changing my code with the following: applying the scale to the prim before doing the positioning, the positioning engine would center the prim with its actualSize: after the scale was applied. I first thought it would be the right solution: apply scale and rotation (in respect of origin as always) before the positioning engine, but now consider this: You create a prim with origin 0,0, align it at left and then make it spin by increment its rotation each frame. The result is a prim that rotates around its left/bottom corner (imagine the motion, the prim doesn't rotate around its center, but rotation forming a large circle with its right/top corner). How will the align left behave in this situation? I mean I can code it, it's easy, but the result would be weird, don't you think? At least I do, I don't think it as a solution... So what is the solution? That's my question for you guys and I need your input/feedback/thoughts, anything. Would the solution be applying the scale before the positioning and the rotation after, would it make more sense? I already have two scales internally: one you know about and a "post" scale I had to introduce to fix a bug reported by @TMTH where a Sprite with a SpriteSize of 64 and a Size (display size) of 100 was not positioned correctly, because I was changing the scale to 1.5 (roughly) for the sprite to be 100 on screen and it was bad because scale was considering origin and I needed a scale that wasn't, so I've introduced a postScale, computed at the very end. Anyway, I could introduce a third scale, (a second for the user), which would be a preScale and that would be applied before everything, I think it would solve @royibernthal issues. But I don't know if it's clever to expose to the user more than one scale property. So basically, I need to know what you guys want when positioning is used with primitive rotation/scale, because now that's what is missing: a behavior, a model that fits any needs. So please take the time to think about it as much as needed and...talk, give me Use Cases, propose solution if you can, anything! Thanks
  5. I don't support Device Pixel Ratio (DPR) and I don't think I support a change of setHardwareScalingLevel other than the default value 1. I'll take a closer look asap if I can at least support the hardwareScalingLevel and let you know.
  6. Hello @TMTH I've made the changes, I've built a BMFont map with the Arial font and the text is now displayed correctly. There's a new preview build reflecting these changes. If you have feedback, they are welcomed!
  7. I've never had such issue, but I've never used OptimizeAsync of SceneOptimizer, please keep me posted if it's the issue. It's most likely that I don't reset some states as expected. I've tried your URL but I don't see Canvas2D content, can you tell me what is drawn with it?
  8. Ok, now I'm reading the doc (RTFM rules...) I understand that it's actually way more complicated than what I did. But I did dead simple, it's not that complicate in absolute, I would even said that it makes more sense to me, the guys did that to pack as tight as possible the chars but still storing values to place them correctly during rendering! (which is btw something I have trouble with when using font converted from HTML because I don't have all these informations). So it's great, now I know what to do and how to improve the rendering thanks to your information, it shouldn't be that hard to code, it's 4 additional properties to store and use.
  9. Ok, so, let's do this step by step If you need text to be displayed following the plane a of 3D object, so not following the plane of the viewport: then a WorldSpaceCanvas (WSC for short) must be used. So I think you made the right decision here. Right! But then you said: there you lost me. Why the size of the WSC is related to the size of the screen? First, use the latest preview version I've commit 1-2 days ago (see this post, an you should follow its thread). Alignment/Positioning is way more reliable now. Now concerning your "extremely small", yes, that's something I've realized few weeks ago, when you set the size of your WSC it's in pixel but it must match the 3D World Coordinates and something (well, most of the time I should say) these two coordinates systems are totally unrelated. But you need to keep the ratio between the 3D world plane and the WSC that is created. So I've introduced lately the "unitScaleFactor" setting at the WSC's construction, to apply a scale factor on the WSC that will be created. Example: you need a WSC to be 40x80 in 3D world coordinates (for instance this is the size of your 3D card), but in order to display text correctly you need a bigger surface, if it's something like 120*240 then you have to set a unitScaleFactor of 3. This way you're dealing with a WSC that is "more suited" for text rendering/fontsize. I hope that my answer above is the solution to this. tell me if I'm correct. About Performances Because it's like size, it matters after all, no matter what they say! If your WSC's content don't change (in your case if the text is pretty much static) it won't be rendered... To say it more clearly: the WSC's is rendered only if there are changes made. So if there're none, it's rendered one time for good. Then after the deal is it will add one draw call to draw your custom node. If you have 120 custom node, then it's 120 Draw Calls, I don't think it would slow things down that much. but if it's a concern and that you manage to make all your card's WSC with the same size, then you should use Mesh.createInstance() to create a InstancedMesh in order to make your 120 Draw Calls just a single one! But first thing first: quality/fidelity, then perf. So let's solve the positioning/text quality first. One last thing, once the font size you set is pretty good (at least 14px) try to use the signedDistanceField mode instead of the superSample one.
  10. I just recheck my code, thing is: I don't need to compute the position of the next char, right? I can just use the x and y position for this, right? I mean they are absolute values, right? If that's so, then I don't need xadvance
  11. Ok, I apparently I didn't look my code closer enough, let's go again then!
  12. I was wondering if you were talking about spriteWidth and spriteHeight properties that could have been added... To be honest at first there were only a size property, I've added width and height after because if you do myPrim.size.width += 10 it wouldn't trigger a change...
  13. Well, I was a bit too pessimistic! With a Design size set with 400, 300 (to have a smaller rect because you set their size with 10, 5), I also have the expected result with both designUseHorizAxis true or false! So I'll say: give it a new try!
  14. I'm working on it, apparently, there's work to do! The non design mode is now working as expected thank to the positioning engine rewritting. But the design mode counterpart doesn't seem to work, so I'm on it.
  15. @TMTH I've removed the two lines that force the address mode to clamp.