Jump to content

L B

Members
  • Posts

    967
  • Joined

  • Last visited

Posts posted by L B

  1. Interesting part at 23 seconds:

    Vine is probably arranged in bunches, which seems to be enough precision for games. Perhaps this is the way to go.

  2. The generation code is already provided. I'm just wondering how to make the display of the ivy possible in real-time.

     

    P. S. : I don't think you get benefits of instancing with bones. The main reason is that entities will geometrically differ. On static entities, LE sends the matrix information to the GPU instead of the poly information, which is why we get instancing benefits (I think).

     

    Again, if Josh could enlighten us...

  3. I get around 45KT initially for a small vine. This might be -15KT for the roots, /2 for the 1poly/leaf, so ~15KT for a small vine.

     

    Definitely not viable if we want to have a diversity of vines.

  4. My guess performance wise would be to generate a bigger portion of a vine as a single mesh. You can easily create an empty mesh with LE and then add surfaces to it, as your vine grows. That way a generated vine would be just one entity which will make it much faster to render. I can't comment on the OpenGL 3D line, as i never used OpenGL 3D commands directly.

    I'm afraid what what we gain by decreasing the entity-count, we lose by not using the same 1-polygon mesh instanced multiple times (which Josh keeps saying is as fast as it gets). I'd be curious to know what Mr. thinks of this.

  5. Extending the laws of your own country to those of others is to make huge assumptions and the general deciding factor in many of these types of cases is not whether it is legal or not but whether you can afford to fight it should the employer take you to court. You will undoubtedly have lost your job by then and depending on the country may not have access to state funding to fight such a case. I doubt a company would do this over a couple of shaders but the point stands!

     

    I'm sure Lord Hippo will come to whatever conclusions and decisions are right for him, he is obviously an intelligent person and more than capable of weighing these things up for himself. At least he has shown us some possibilities with shaders and as such it could be done by others.

     

    Oh, Iran. Didn't see that.

  6. I think I'll use the usual Sponza model for testing (usually used in GI algorithms tests):

    Sponza00GI.jpg

     

    The results could try reproducing this image:

    Alejandro_Ruano_01.jpg

     

    For the branch, I could use OpenGL to draw 3D lines instead of polygons - think it's a good idea?

  7. I'm going to try generating ivy in Leadwerks, in real-time. The beauty of IV comes from its individual leaves, so I'm asking for some optimisation tips.

     

    Here is a beautiful ivy renderer: http://graphics.uni-.../ivy_generator/

     

    Obviously this is not RT.

     

    I'm thinking I can harvest the power of Leadwerks instancing to achieve the result. 1 triangle per leaf is possible (with the right UV setup). The problem might be the massive amount of entities. How do you suggest I do that?

     

    Of course I can use billboards in the distance, but again, the entity count will be high. Perhaps I should avoid entites, but I don't know how.

     

    I don't need tips on the actual generation algorithms, I'm getting pretty good at this. Just on the performance aspect.

    EDIT: Actually, it's open-source, so I might just port it to Leadwerks. It's even allowed for commercial projects.

  8. Of course, if your employer requested the shader for a product, and stipulates in a signed contract and/or agreement with you that all works produced within X period, including shaders, are the company's intellectual property, then don't complain; it's normal that you can't release it.

     

    But that's rarely if ever the case for junior programming jobs. And considering LordHippo is 21, this one job probably is. Employers tend to be very loose on contracts, if even there is a contract. I developed, for example, a whole CMS for my employer, which I could legally resell. All I got from my employer was an informal email telling me not to do that, almost with a pretty please.

     

    Truth is, all that matters is legality. Employers, especially greedy and bad ones, tend to use intimidation and exploit the ignorance of junior employees in order to abuse their intellectual property or other work rights. But it's not legal, therefore it doesn't stand.

  9. Haha. Simple, hilarious and effective. Moreover, upload it to a reliable code directory like Google Code, so that the upload date can be trusted and grant you prior copyrighting.

     

    In any case, any original code you write is copyrighted to you, notice or not, unless you specify otherwise in a written manner (e. g. contract).

  10. Unless he can legally bind your code to his company by a contract, he may not stop you from publishing your code. Now, the legal part of this will hang in a couple of factors, all depending on said contract (if it exists), including whether you coded this on your work hours (assuming you're not doing freelance task-oriented work but workplace hours), whether this shader was requested for the product, etc.

     

    If he threatens to fire you or whatnot, without legal backup, you can contact work protection agencies in your area who will gladly support you in fighting back.

     

    Chances are that if he seems to feel threatened, he simply realized that you did a great shader and tries to take it from you, without that being in his right.

  11. Lazlo - As I stated above, I don't believe that is how MC works at all. I'm open to the fact that Notch is a fairly bad developer, but you're missing a few critical points about such a system:

    1. The code is only ever traversing and displaying the outer area of the volume. Using octree's or similar you can efficiently 'walk' the volume to read only the outside cubes. A 128x128x128 volume, if completely solid, will only render as approx 768 cubes out of some 2 million. That's your best case scenario obviously, but you can see that it is a massive improvement.

    2. You do not draw the entire cube - You only draw the faces of the cube that are on the outer shell of the surface. That'll cut more than half of your polygon count again.

    3. If you don't plan on using models then you best way forward is to use the Marching Cubes algorithm to run a surface extraction on a volume of map data. It will give you the outer shell in one solid mesh.

    4. Leadwerks unfortunately is not able to scale very well out of the box with large amounts of random entities - Its occlusion system will chew up much more time than worth while for games that implement many simple entities. You need to disable it and write your own workaround or make it more efficient by using its grouping features. Do a search on the forum - I started a thread on this some months back.

     

    I believe both systems are used: precaching nearby chunks, and using octree for outer cubes and drawing only outer faces.

     

    As to using octree to only display outer cubes, I think we'd have to play with more algorithms than are built-in Leadwerks. Besides, considering how Minecraft works, say you break an outer block, you want to load the one behind, and thus perhaps a preload of ~3 cube depth from the surface should be used. What do you think?

     

    As to drawing only outer faces, I can't say really. I'm far from knowing anything worthwhile in 3D render programming, but doesn't basic culling prevent from the GPU computing invisible (hidden by depth) faces? If it is so, there's no more algorithm to be added.

  12. If you keep increasing the numbers geometrically, you will eventually run into problems. 32*32 = 1024. 128*128 = 16384. That many entities is not possible. You will need to do something more advanced, like collapse them into a single mesh. I'm pretty sure Minecraft does something like this, probably breaking the world into 16x16 or 32x32 chunks, and reconstructing single meshes for each chunk based on what voxels are filled.

    Minecraft breaks in (XYZ) 32x128x32 chunks. 64 above surface and 64 below. I suspect the chunk you are in is "active", and probably even the 8 surrounding ones. That means 32x128x32x9=1 179 648 entities, if they're not air-filled (which IMO takes roughly 40% in Minecraft), so let's say about 700 000 cubes.

     

    700K active cubes? IDK how to handle that. They're not fusioned because you're close from them, so modification would be costly.

     

    How do you think we could handle that?

     

    First, we could have 16x16x16 chunks, and we'd have 3x3x3 of them loaded at once (cubic area around us), so 16x16x16x3x3x3=110 592 active cubes. Times ~60% (assuming we have some 40% air, usually), 66 355 cubes.

     

    Say we have about 70K cubes to handle. Better than 700. The price for dropping to that was that we have to switch between prerendered versions and active versions more often as the player moves in the world. That might be costly, but might not as well. We'd have to test.

     

    Theoretically, if the loading time of up to 15 chunks (~40K cubes) (assuming you move diagonally on the X, Y, and Z axis at once) is smaller than the time taken to traverse a chunk, there is no problem, because surrounding chunks can be loaded faster than the player accesses them (hence the whole advantage of having surrounding chunks preloaded).

     

    Loading 15 chunks is the most extreme case. All other cases, when moving along the X, Y or Z axis of 1 chunk would require the load of 9 chunks (~25K cubes).

     

    Assuming 1 cube is 1 meter (as Minecraft handles it), and the player jogs at about ~10km/h, traversing a chunk of 16 meters (the minimum time, in a straight line), would take 5.75 seconds (let's say 6). This means that loading 25K cubes has to happen under 6 seconds. I think it's feasible. On another thread, it could happen seamlessly.

     

    If you walk in a diagonal, in which case we reach the 15 chunks case, you have to do a distance of about 28 meters, in a straight line. This would take about 10 seconds. This means we have to load 40K cubes in 10 seconds, again, I think it's possible on another thread.

     

    This means you have to load approximately 4K cubes per second. If Leadwerks 2 can do that, we're in business. in terms of polygons, this is 48K polygons per second, but I don't think this ratio is relevant. Polygons per second, lol. Remember though that cubes might sometimes be rounded (>12 polys). And can have some kind of props or other things.

  13. For many implementations I would want it on bright surfaces as well. If ever this is released, I'd be thrilled to know how to make it work regardless of the lighting amount.

     

    I'll ask again though, will it be released? It's truly incredible.

    • Upvote 1
  14. That was an ambiguous statement. :)

    That means I'll be the one maintaining the VS2010 C# project for .NET 4, I guess.

    But think of all the functions that have optional parameters in L3D. You can't have that with VS2008 C#.

     

    EDIT: You can make overloaded functions with less parameters, of course, but it's annoying, long and useless when you could use the proper technology.

  15. My point is that the real behavior people carry out will be to not make installers with the VC2010 redistrib built in.

     

    You have no idea how many people email me asking why their Leadwerks project won't run on their secretary's / grandma's / son's computer.

     

    Ok, yes, we get your point:

    • Developers might not be able to add the redist to an installer
    • Users might not be able to correctly install said redist

     

    Now here's the counter-argument: Don't settle for old technologies, you'll be switching in 6 months anyway. And that's probably before the official release date of L3D, so it really might be worth considering.

     

    Also, did I mention C# and .NET 4 require VS2010? This means language improvements that C# coders have started using regularly, like optional parameters, that Leadwerks wouldn't support.

     

    And if you're worried about the installers, make a distribution guide or whatnot. An example NSIS script. It really can't be hard to figure out once and then put in the distro.

×
×
  • Create New...