• Content count

  • Joined

  • Last visited

  • Days Won


jerome last won the day on February 9

jerome had the most liked content!


About jerome

  • Rank
    Advanced Member
  • Birthday 03/17/1970

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    France / Rodez

Recent Profile Visitors

2,402 profile views
  1. What would a terrain be without some collision detection features ? Here's the first working prototype of terrain.getHeightFromMap(x ,z) in action : Not yet documented (*), but already working : (*) Actually all the methods are documented in code comments, so if you generate a doc from the code, you can already get the API documentation.
  2. Well, Adam is right... I kept a distant bad experience in mind where the declaration order wasn't respected. But it is. And it shall be : Whatever the actual download order or delay. Please don't take notice of my former post.
  3. Maybe I was too optimistic by saying I could finish by the end of this week I just can't have a working function getHeightAt(x ,z)
  4. Actually the declaration order of the <script> tags doesn't really matter, because the download time of each file is unpredictable. Each JS file is downloaded by the browser at its own variable speed (depending so many things : the web server charge, the network charge, the hypothetical different paths to different hosts, each file size, etc) and is run just after it's received. So whatever the declaration order the first declared JS file may be run after the last declared one. And vice-versa. Imho, the right thing to do would be to bind each dependency execution to some core events... Example : window.onload (here, we're sure that everything is completely downloaded) = run your code what calls some BJS functions (we are also sure that BJS is downloaded and run) If a dependant lib needs that BJS is already accessible (loaded or run) because it calls alone some BJS functions by its own (something different than : the user call a lib function what calls a core function), it should rely on the same process.
  5. How do you expect your texture to be ?
  6. I'll complete the last part of the code before the end of the week (hope so). Then I will write the documentation... painful work because, although the API is quite simple, there's much to explain.
  7. These aren't our choices, but the W3C ones : all the browsers only know the WebGL layer. How they communicate with the native or lower layers is just a matter of OS and/or browser implementation, things on what we don't have any control at the javascript level. In short : up now, when you're using a browser, you're using only WebGL.
  8. I talked with the great boss and he allowed me to add this feature with an extra parameter in the box constructor. So I will do it... sooner or later, because I'm currently busy with something else for now.
  9. If you use a GroundMesh, you may know what is the current ground altitude at any (x, z) coordinates with whatever its shape
  10. Why don't you just switch the light off when it's under the ground ?
  11. OK, I just understood what you said by seeing your texture. I need to think about this.
  12. First working port to TS and first working compiled minified version here : doc to come
  13. Your need seems really specific so I don't think there's a dedicated easy way to do if I understand well what you're trying to achieve (rotation of a given texture face). I think the fastest way (in LOC number) would be to modify directly the vertex data UVs array, knowing that a box is built with 24 vertices in BJS : the first 24 are the player's head, the following 24 are the the body, the arms, etc. [EDIT] Unless you set the particles uvs after the SPS is built, you can also set more accurately the UVs on the box models :
  14. Well, just define a translation matrix to shift everything for 0.5 down (0, -0.5, 0) a the line 45 Apply then this translation to each model vertices that needs to be shifted down : legs and arms and bake this transformation in the local space with bakeTransformIntoVertices(). Now each shifted model is build 0.5 under the origin in its local space. Its rotation pivot is still the local origin, ok ? So don't forget to position each particle 0.5 higher than the initial values and here's the result : [EDIT] btw, it seems all your player members (legs and arms) have the same identical model. So one single model box would be enough imho.
  15. as said formerly, you can always modify the model before inserting in the SPS : if you translate a mesh in its local space, then bake it, it will not be centered any longer. This is the same than changing its pivot point. Since a solid particle always rotates around its local space origin, this particle built from a locally translated mesh model would then rotate like if its pivot point weren't centered.