Jump to content

tournamentdan

Members
  • Posts

    712
  • Joined

  • Last visited

Posts posted by tournamentdan

  1. If you draw a single quad and tessellate it, you will lose the ability to show and hide sections of the terrain, even areas behind the camera.

     

    Sorry, I missed that you said single quad.(I must need glasses) It would be nice to reduce the file size of each model down to that extreme low but is not very practical to start each model out a single plane. If we could, sure we would be able to load a very large amount of objects into a map but, you can over tessellate a object. When I say this I do not necessarily mean the whole object, but sections of that model. You would not be able to make human figure from a single cube because were the arms,legs,head would try to tessellate and extend out would create way to many small triangles in that area. For instance a tess factor of 3 will give you 13 triangles for every single triangle. So it can get out of hand quickly and I believe that the hardware likes each triangle to be at least 8 pixels.

     

    If we could tessellate every object we can reduce memory greatly and which help speed things up a bit.

     

    Would LE2 be any faster if you only had to load the lowest LOD?

  2. Sorry, I didn't realize the image was linked from the gallery. I removed the image in the gallery because it didn't belong in the LE2 gallery. You can attach the image in your post if you like.

     

     

    They chucked a single vertex buffer at the GPU, which is the worst way you can render terrain. LE2 renders a set of instanced patches, and uses the displacement map for the height info.

     

     

    If you draw a single quad and tessellate it, you will lose the ability to show and hide sections of the terrain, even areas behind the camera. That means the tessellated approach will have to process maybe 3-4 times as many vertices. Because the tessellation pipeline is completely programmable, the hardware can't anticipate and cull offscreen patches. That discrepancy won't be apparent when you are rendering the whole terrain onscreen at once.

     

    Now you can still use tessellation on terrain patches, and have the speed of our existing terrain rendering, along with fine surface geometry detail. This reinforces my original statement, that tessellation is good for surface detail and not really useful aside from that.

     

     

    You and most people on this site are at least ten times smarter than me. Most of this stuff I learn as I go. So I mostly trust and go by things that you and others say. My job takes me away from home weekly so I do not have a lot of time to learn this stuff. I can only go by the things that I read. So please inform me if the stuff that I am finding on the wonderfull world wide web is just a load of ****.

     

     

    I am a little confused on how you are going to use tessellation in LE3. The only way I can see to benefit from it is to use distance adaptive tessellation. With out this, tessellation is useless.

    Yes the speed will be the same(because you are rendering the same amount of ploys) but if you use distance adaptive tessellation you lower the detail far from the camera and add it close. So the real detail will be so much better up close.

     

    I was under the impression that you could cull with tessellation. Here is a pic of page 47 of the first link on post number six.post-570-0-17267600-1310264883_thumb.png

    And page 48.post-570-0-60415200-1310265013_thumb.png

     

    And one from the 2010 GDC.post-570-0-15918600-1310265196_thumb.png

     

    Again you and others here do this stuff every day so I do apologize if I am miss understanding the info that I take in.

  3. I already have it implemented.

     

     

    That image is so incredibly misleading. They are comparing a tessellated terrain to the most inefficient possible method of rendering terrain, and dismiss the displacement map in their memory totals

     

    The old ATI tessellation extensions are not the same thing as OpenGL4/DX11 tessellation shaders.

     

    For one do not erase a pic that I provide for info. It is not like it has anything to do with any competitor of yours. Of coarse they compared tessellation to the worst most inefficient method, because no matter what you do with a normal or bump map or any way that you try to cheat. It will not be as good as high detail. Meaning high polygon. That is why they compared high poly terrain to tessellated terrain. And they did not add the displacement to both terrain. Sure it may lie a little about the total memory but then on the other hand they did not add normal maps or any texture. All that matters is both have the same detail. Which is better?

  4. Tessellation and LOD don't really have anything to do with each other.

     

    Unfortunately, I can't rely on tessellation for terrain LOD because it only works on a very small fraction of total supported hardware. It would be awesome to just draw a quad and let the GPU create all the terrain detail dynamically by distance. I don't think the results would be much different, but it would cut down on the complexity of the code I write.

     

    There's a lot of confusion about tessellation, and I think they've done a poor job of explaining it. As I see it, tessellation is the final answer to surface detail. First there was plain diffuse textures, then bumpmapping, then various parallax shaders, and finally real surface geometry with tessellation.

     

    You could replace LOD with carefully designed tessellated models, but it require your assets be modeled that way to begin with, and since it would only work with SM5 cards I don't see this being relied on any time soon.

     

    Tessellation detail is controllable dynamically in the shader, so you just supply a detail parameter, and then my shader will use that in the calculation. The shader actually has to calculate distance from camera, so it's quite low-level. Changing detail level on the fly is no problem.

     

     

    Tessellation adds and subtracts polygons and you base that on how close the camera is, so LODs and tessellation are very similar. They both help you cram as many polys as possible.

     

     

    ATI has supported tessellation for years on their GPU's just did not have the tech to unlock it. So I do not see a problem with hardware.

     

     

    And what I am finding, you use displacement maps for the calculation of the tessellation. For instance instead of me creating multiple LOD's. I would only create one high poly model with a displacement map. The tessellation would then add and or subtract depending on the distance from camera. So it would be MUCH easier to create one model and one displacement map than to create a bunch of LOD's. You could create a displacement map of your terrain, so I do not understand the problem for that also.

    Using tessellation for terrain is going to be a huge difference in performance.

    Here is a list of some games that use it.

     

    Metro 2033

    Stalker: Call of Pripyat

    Civilization V

    HAWX 2

    Dirt 2

    Alien vs Predator

    Crysis 2

     

    Also here is some info I found from the GDC of 2008.

    gallery_570_95_411522.png

     

    EDIT:: photo is now Attached.post-570-0-99391600-1310261222_thumb.png

     

    This is also a nice blog post from a couple years ago with info on tessellation.

    • Upvote 1
  5. 1. Yes.

     

    2. Like LE2, the LOD distances will be near, medium, far, infinite, with control over what each of those values is. This is so the engine can sort objects in a list of objects for each distance, and discard far away objects without having to iterate through each one. For example, if the "far" distance is 200, and the closest point between the camera and a certain octree node is 220, then we know we don't have to check any of the entities in the "far" list for that node.

     

    Ok great. So just to be clear on your answer number 2, controlling tessellation will be just like controlling a LOD. Like

    example for terrain.
  6. In LE3 will we have the ability to have LOD and tessellation. I see that tessellation is good for some things and not for others.

     

    And will we have the ability to control the tessellation on a per object from the distance from the camera or will it be everything at the same time in the camera view?

  7. Yes thank you for your work on this. Implementing this AI engine into Leadwerks will no doubt make LE2 and LE3, easier for less qualified programmers like me:(.

  8. I thought LE3 will only allow 256 players, or are we talking about using raknet to make a mmofps.

     

     

    And I hate to bring up a sore subject but how is it possible to create a mmofps with out multi thread.

  9. You might want to check out reknit now. It could give you a head start on networking and can only help learn how things work for when Josh has his networking going. Note that loading on a separate thread and having a player join a game in progress isn't really a direct linked issue. Currently what you would do is load every character type at least once so when a new person joins they aren't loading a new asset, they would just be creating another instance of an existing asset which is as close to instant as you can get and won't cause any close down to the game in progress.

     

     

    Thanks Rick for the info. I was kind of hoping to have custom characters for the players, so I would not be able to do it that way. But I guess if I have to compromise and only offer a few different characters, it would not be the end of the world.

  10. You might want to cast you eyes over this recent spec for LE3

     

     

    Wow!!! Everything on that list looks great. Especially Networking. I was hoping We would have the ability to create large multi-player maps.

    Has anybody seen if Josh has or has not decided to allow loading models on a separate thread. I was wondering, If we can not load on a separate thread does that mean also for networking that a player could not join a game in progress. Everybody would have to sync together when the game is not running, right?

  11. You can put any characters in a string. It doesn't matter for the compiler if it's C++ source code, since it's just characters, but you have to escape the " characters with \", else the string is terminated at the first ". Linefeeds need to be escaped with \n and multiple lines need to be merged with \ at the end of the source line.

     

    Thanks for setting me strait.

  12. Is there a possible way to place lines of code in a string or will a compiler try to read the string as code and give a error?

     

    #include <iostream>

     

    using namespace std;

     

    int main()

    {

    string script;

    script = "#include <iostream>

     

    using namespace std;

     

    int main()

    {

    cout <<"hello world"<< endl;

    return 0;";

    }

    cout << script << endl;

    return 0;

    }

  13. I don't know about their business plan. I can't even figure out how much anything would cost.

    It is kind of confusing. I have been checking it out. To get the discount price you need to subscribe. If you pay 89.97 for three months you get one month free. You also get four credits to buy clips with. You can not pay for the custom characters with credits. Each clip will cost anywhere from one to four credits depending on complexity. After you use those credits you can then buy clips at the discounted price. It does not give the exact credit price for clips but I can only guess it would cost four credits for the $25 clips.

     

    $39 for a pro character

    $89 for one to four clips and a opportunity to buy other clips at the discounted price.

     

    So if you use four credits for one clip and then buy three more at say five bucks a piece. It will cost $143.00 per character. Yes you have to buy the same clip multiple times for different characters. They have excellent tools that I would love to play around with. To me it just sounds a bit much.

     

    If everyone is fine with these prices I may have to rethink what I might charge.

  14. good luck. i'm not saying your not an animator, not knowing your background or skills, but it is a difficult skill to master technically & you either have artistic ability or you dont. walk and run cycles are easy technically, but dont assume it is easy to introduce personality and style to that cycle or any animation. if you produced a backflip animation for 5$ that i would be happy to use, i'd tip my hat to you (then probably eat it) then suggest you send your cv to an animation studio.

     

    All of Mixamo animations are done with motion capture technology, which is what I will be doing also. You are absolutely right animating by hand is very hard and time consuming. But you can stream line things and use what tools there are so you can sell things at a cheaper price.

  15. Thanks for replies. A tut on Blender would be very usefull.

     

    I am still looking in to this rig add on for blender. A new version just came out and I really do not know about the previous versions but this rig does not work with bones so I do not think any mo- cap files will work with it. It is a cage that deforms the mesh. It will skin and rig a character very quickly. It also will give you a ik,fk,hinge and stretch rig. You would have to animate your self and export but looks promising.

     

  16. so 25$ per animation = good price. Marleys Ghost is absolutely correct. if you created a 2 second clip of say someone doing a back flip to sell in the upcoming store, you would be asking what price?

     

    In the future I plan to sell characters fully rigged(face also) with some basic animation(walking, running, smile,anger ect..) for less than their pro character which is $39. Custom characters will be more, and I would think five dollars or less for a 2 second back flip clip would be fine. I think a lot more people would buy things like these if you made them a little more affordable. Which would give you more profit.

  17. not trying to pick a fight with you, tournamentdan (I think you've got some

    idea how much effort/energy/experience goes into making 'good' art)

    but those animations seem to be about $25 or less. If you built your pipeline around

    their naming conventions/rig you'd save a huge amount compared to paying an animator.

     

    It just baffles me how there's this perception that art should somehow be less costly

    than other things that take an equal amount of skill, knowledge/experience, and time

    to create.

     

    I'm currently going to Animation Mentor and I can tell you for a FACT that a reasonably

    polished run cycle will take waay more than 1 hour's work to make look decent...

    (gets off soapbox)

    Absolutely animating and anything else that has to do with the creation of games takes time and effort. Of course time equals money. I just feel that $25 for a 2 second animation is a bit much especially if everybody and their mother can have the same animation.

     

    I just went back to their site and noticed two prices. One for non subscribers and one cheaper if you subscribe. The cheaper price is a lot better but I kind of do not like the subscribe part.

     

    Again I am totaly on board for anybody making money for what they do.

     

    I just recently bought some mo-cap software for face and body and will probably offer a service some point in the future with no subscription and very affordable.

  18. Using a flow graph to control verts is interesting and I can see how it can or could get expensive when it comes to performance.

     

    I have not messed with it yet but have done a little reading on shape keys in blender and accentually what you are doing is creating a library of different face shapes. Happy face,sad face, mean face ect... Each individual shape key is just another model . I bought a tutorial through blender and it came with all of the model files. I was playing around with one of their characters and noticed that it was eating up a lot of memory. Did some digging into the files and found that the library of shape keys were most of the data. Around 17.MB So this would probably not be ideal for real time either.

     

    Some times(most times) I like to be lazy and find the easiest ways to do things. Yesterday I found

    nice motion capture software. It would take a lot of playing around but you could probably get some nice results.
  19. You can't write an engine in C#. It would be horribly slow.

     

    If the end user could only use C# for XNA programming, that would be okayish, but there's no way I can rewrite the whole engine just for one platform. I doubt they would allow Lua either, and that it is pretty bad.

     

    The consoles are sort of a chicken/egg problem, but I predict once we have a mature LE3 product, it won't really be that hard to gain access to the dev kits. It's a harder sale when I have a product that's in development, and no history of console game development. I would have preferred to include consoles in development from day one, but I think it will work out okay. I can use the initial sales from LE3 on other platforms to hire console specialists for the port when we're ready.

    I will have to agree here. Like Josh has stated before. Sony can be picky on who they give a license to, but I am sure they are like everybody else and like to make money. If you make a kick bum game for the PC I am sure they will jump on the band wagon.

×
×
  • Create New...