Jump to content

L B

Members
  • Posts

    967
  • Joined

  • Last visited

Posts posted by L B

  1. I think Mirror's Edge is baked, not real-time.

     

     

    As far as I know, the only realtime GI that actually works, is the one that Crytek has implemented. There are some papers describing it, and you can find it in NVidia DirectX samples including source code and the papers.

    But this method is not being used in any real game, even in Crysis2.

     

    But maybe you can find a non-global solution for your specific problem.

     

    Unreal Engine 4 seems to do it as well. ParaToxic, I sent you a PM with the video.

  2. Do it well, but don't release it months after the release -- it's a critical feature. I also go by the philosophy of doing from scratch, yourself, but sometimes you have to admit that some libraries exist that already do it well. Weigh the possibilities.

     

    People will start coding crappy GUI alternatives from scratch and redo them later.

    • Upvote 2
  3. If you're serious about making games, mobile is where all the opportunity is. You can release an okayish game on PC and you won't even be able to give it away. Release the same game for mobile and you're a superstar.

     

    Mobile is where I expect most of our sales to come from, based on the feedback I've gotten so far. I'm still building the engine to be scalable, because I want to return to high-end PC graphics, but trying to make a business on that alone will fail.

     

    Yay! And thus, Leadwerks died to profit.

  4. It will be called RocksHD and feature lots of new rocks, stones and cliff models for your game-world.

     

    ...and feature lots of new rocks, stones and cliff models for your ...

     

    ...rocks, stones and cliff models ...

     

    ... cliff models ...

     

    me_gusta_mucho_by_megustamuchoplz-d416uqk.png?1319690633

  5. There have been many discussions about culling performance. Notably:

    Josh often says that he needs a scene file to test. Here is one, along with the 3D model "filler.gmf" used in it.

    Here is a screenshot of the performance assessment:

    post-28-0-96510800-1327615026_thumb.png

     

    I want to stress the following points:

    • The polygon count is 25k, which is nothing for Leadwerks. Draw time is 1ms.
    • The world time is of 7ms, 5 of which are taken by entity cull time. This is enormous. I often get 6 or even 7ms taken by the cull time, out of the total 7ms.
    • There seems to be 2376 entities drawn, whereas the square is 24x24=576 cubes. The other entities are the directional light. Perhaps the LOD counts as 2, but even then, it's not 2376.

    If you don't see performance drops yet, try multiplying that grid 4, 8, or 16 times. Then you'll notice cull time starts to rise in the 30-60ms.

     

    Another interesting point is that when you look down from the basic camera view, there seems to be a massive glitch in culling. Although no entities are in view (screenshot shows some only to indicate how I lowered the view, but you can lower further to show none), almost all the entities and polygons are still drawn. Also note that culling still takes the most of the render time. This seems to indicate frustrum culling is not only slow but bugged.

    post-28-0-90566700-1327615431_thumb.png

     

    This needs to be fixed, as it causes massive drops in performance for apparently no reason. Or, there needs to be a way for us to disable culling in that case. I'm interested in learning how.

  6. Note that Newton supports obtaining joint force (applied?), but it doesn't seem to be implemented in Leadwerks. The documentation pages are off: they seem to have been copied from another function description, and not edited. But the functions and definitions are there:

    The ball joint seems to be properly documented. It should be really easy to implement.

  7. I'd like to know a couple of things about joints:

    Without this, a lot of physics breakage simulation is hard. I could get the force on collision, I guess, but I can think of a case where I'd like the joint to break without any collision, out of the sheer mass suspended to it.

  8. While modeling trees, we generally use a basic technique: a cylinder-like (or cone-like, if you prefer) shape for each branch, and other cylinder/cones of sub-branches branching from it. (That's a lot of "branch", I'm hoping you follow).

     

    Now the usual way to handle trees (and meshes in general) is to have 1 unified "surface", and no intersecting parts. By this I mean that the sub-branches' cones won't dig into the main branch's cone, the modeler will trim off the excess parts inside the main branch, and make it end up nicely.

     

    To compensate for my poor explanation skills, here's a complex schema drawn with my even poorer MSPaint skills:

     

    post-28-0-13364800-1327365820_thumb.jpg

     

    Now, I'm wondering why said "trimming" is good.

    • Does it impact performance positively?
    • Does it remove visual rendering artifacts?
    • Does it lower poly-count?
    • Does it make smoother UV's?

    I actually think I can say it doesn't lower poly-count. Take the followind diagram.

     

    post-28-0-44211700-1327366606_thumb.jpg

     

    On the left, it shows the basic cylinder shape of the main-branch. The red convex polygon marks the intersection of the sub-branch. On the right, you can see the polygon rearrangement done on the main mesh in order to re-triangulate with a hole in the surface left by the trimming. As you can see, trimming actually highers the triangle count. Admittedly, I might not have done the most optimal triangulation for every plane, but I think I'm not far from it. Edit: There is actually 22 triangles if I optimize a little, but it's still more than twice the initial amount.

     

    The other argument I think is bogus is the fact that you can have follow-up, seamless UV's.

    From what I understood after plenty of Googling, artists tend to be creating separate UV maps for each branch, therefore (to my understanding) breaking the follow-up of the bark texture. Of course, they might be moving the maps around and playing with the settings to make the seam as subtle as possible, but it should theoretically still be there.

     

    Here's an image of what I mean. And the source: http://vanessav85.wo.../07/28/tree-uv/

    treebasicuvsetup1.jpg

     

    You can also look at this YouTube video, in which the author uses the same technique, even if he has 1 uniform mesh:

     

    I haven't found another UV mapping technique for trees, so I'm assuming this is the norm.

     

    Now the remaining arguments (assuming I logically ruled out the first two, I'm hoping for input here), is that it removes visual artifacts and impacts performance is some other way. From basic renderings I've done in real time, I haven't seen any graphical artifact, but maybe someone will point a special case where it happens. And as to performance, I don't know what logically would. Perhaps some inner, useless texture lookups, but they'd be very minimal (probably less than 1% of the total area of the tree).

     

    So, why do you artists bother doing that? Quality standard? Any other reason?

  9. This video still is the only interesting use I've seen of tesselation, but I won't be going down that path. I'll try grouping ivy models in patches of ~2K-5K triangles, then instance these.

  10. Unreal engine 3 supports tessellation. I am guessing thats how it is done in that video and most likely the only way to get exactly what you want.

     

    Tesselation is also the only way to calculate the velocity of an african swallow, as well as finding God and the true meaning of life.

×
×
  • Create New...