Jump to content

Rastar

Members
  • Posts

    421
  • Joined

  • Last visited

Everything posted by Rastar

  1. Well, I'm not much of a Blender artist myself, however a quick search gave three interesting Blender add-ons: http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Curve/Sapling_Tree#Instructions http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Curve/Ivy_Gen http://blenderthings.blogspot.nl/p/the-spacetree-blender-add-on.html I would definitely agree that those forester trees don't match the quality of your work, for example (got a few in my collection...), but I thought for someone like me who isn't too much into modeling it is a nice way to quickly generate a variety of acceptable models.
  2. Don't know if that's been mentioned here before, but I just stumbled across a very nice tree generator, Forester Pro (http://www.hptware.co.uk/forester.htm). You start from tree templates (you can create custom ones as well) and change/randomize several parameters to create new tree variants. It really has a lot of functionality and costs just $20 for an indie license (there is a lite version for non-comercial purposes as well).
  3. There were some posts on this, e.g. http://www.leadwerks.com/werkspace/topic/6162-le3-how-many-dynamic-lights/page__hl__dynamic+light http://www.leadwerks.com/werkspace/topic/7194-dynamic-lights-only-3-visible/page__hl__dynamic+light According to them (haven't tried it myself) you can have more than 4, but only the 4 closest to the camera will be rendered.
  4. Thanks for the link! Yes, I saw that. It might actually be too good for my purposes, and it's still quite hefty in terms of resources (e.g. they need about 45 MB memory per tree model for the z-tree thing. The second (older) paper I linked uses a tiled volumetric texture which sounds lighter in terms of requirements, but they are ignoring dynamic lighting. Still, what a fascinating topic! If only if were a little more knowledgeable... :-)
  5. I just tried to use the C++ 11 libs with my project (llvm libc++), but that gave me tons of linking problems with Leadwerks code. So this isn't possible? Is there a way to get that working?
  6. I've recently downloaded the last LE3 update, and since then can't get new projects running in the editor. I already did a completely fresh install, but no luck. Creating new projects (either for C++or Lua) will crash the editor immediately when loaded (see attachment for stacktrace). "Darkness Awaits" loads in the editor, though. However, the projects are created on disk, and I can compile and run them in XCode.
  7. Ouch, I've found some articles on this topic - pretty complex stuff (sigh). At least some of them are working along the line I was considering... :-) If somebody's interested, here are some links: http://hal.inria.fr/hal-00650120/en http://www-evasion.imag.fr/Publications/2004/DN04/RealtimeForest_egsr04.pdf
  8. I'm thinking about how best to do massive forests for my game. With the large landscapes that I need, I have often have valleys, hills and mountains with large forests. In the far away distance (like 20 km) they can be done just by a green texture. In the close distance, tree models along with something like billboarding, impostors or the like would be OK. But there is the middle distance, say riding along the highway and seeing the forest 1-2 km away, where the trees look like a fluffy-foamy greenish mass. Doing these even with billboards would be a waste. Is there a technique for pre-rendering a forest like this? I was thinking of procedurally populating the forests with (tens of) thousands of trees using models at design-time and then generating a texture and normal map and maybe a mesh, and then discarding the trees. Would that work? Has that been done? Are there maybe papers or blog posts about something like this? I've googled a bit but couldn't find anything. Any help or link would be greatly appreciated!
  9. Interesting article and awesome stuff! The concentric textures reminded me of the geometry clipmapping technique for terrains as describes in GPU Gems 2. Maybe this can be used together for vast Terrains?
  10. I, too, agree with Aggror: Posting in the suggestion box in a bit like shouting in the void and waiting for the echo ;-) We usually only get feedback if Josh strongly objects an idea. I have posted it a couple of times, and I'll do it again here: It would be great to have more transparency in this process, and I still think a ticket system like Mantis or something similar would really help here. We could classify suggestions as high-medium-low or something from our point of view, and Josh could prioritize them as well from his side. Tickets could be rejected, closed, scheduled for a release. That way everybody knows where things are. And, again: Proper release notes would be for free as well and easier to read than scanning umpteen forum posts for the final status.
  11. I loved the SWAT 3/4 games as well, because trying *not* to shoot added a level of suspense (and probably suited my pacifist mind )
  12. On a second thought, at least for my use case something like a Chunked LOD system might actually be better. E.g. while driving along a mountain side or passing the top you will have a pretty far view, but I only need detailed terrain clode to the roads. And since the player is confined to the roads, many of the tiles on the hierarchical LOD tree could be pruned in advance. Even though most of the implementation details required for that are new to me, I might give it a try (if only because it's interesting and fun). Now the question is: Would I be able to integrate this homebrew terrain with the rest of Leadwerks? In the sense that my classes provide the terrain mesh while the rest like texturing etc. would be standard Leadwerks? A very vague question, I know, but maybe there is already a simple answer.
  13. It's actually even more esoteric than that... :-) It's more a fitness app than a game, where people use an indoor cycling trainer to ride (real-life) courses. Yes, that actually *is* boring, but the idea is to make indoor cycling less boring than before. Yes, maybe 200km might be a bit too large, because that would mean you do a complete Tour de France stage (thought I' wouldn't be surprised if there are some freaks who might do that...), but 30-50km would be a rather normal training session. I know this isn't your standard use case, but with larger landscapes becoming more common these days I think it is a feature that other Leadwerks games might be using as well.
  14. By now I consider that a lacking feature of many OOP languages. Some languages (e.g. Scala on the JVM) have an identical syntax for a plain member variable vs a method access. So the client just calls myClass.point and is unaware whether he is just calling the variable, or if a member function does some magic instead. As a class designer, you can just start with the plain variable, and if you later need some code around the access you create a method instead, with client code being unaffected.
  15. But there is a difference between self-contained in the sense of cohesion, making a class not overly dependent on others, and encapsulation, hiding stuff that other classes shouldn't see. I guess Josh was referring to the first.
  16. I am working on a road cycling game where you cover 50-200km per race (read: scene). For that I need to dynamically load terrain tiles, and more than one will be visible at a time. If there is another , easier way to do that, I'd love to know!
  17. I don't think that OOP is overcomplicating things, things really *are* complicated. OOP forces you to adhere to a certain structure, but that structure really is badly needed when code bases grow larger. And there really are a lot of design patterns and best practices to help you with structuring your code. I find thinking in terms of objects quite natural and helpful, but that might be just a matter of taste. That being said, I have more recently moved a little away from those languages and are going now more towards the functional programming style. For one, it's often getting in your way that *everything* has to be (part of) an object. You need just a little function doing something? Well, first create a class and make it a member function of that class... Secondly, I now consider the class-based organization too rigid, because you can look at objects from different angles. You spend a lot of time and coding for enhancing/breaking/modifying objects because the class you (or somebody else) designed is not exactly what you need (and many of the mentioned design patterns are just for that purpose). And lastly, at least with the way the main OOP languages (Java, C#) are designed (shared memory between threads), you will never be able to write error-free, debuggable code for today's multi-core systems. Bottom line: I would guess that many of those 57% disliking OOP don't want to think too much about structuring their code and just type away (which is bad once things get larger). But after doing OOP for more than 15 years, I think the OOP structure really can get in your way and you need something else, at least in addition. Oh well, a lot of text and no clear advice... but I guess that just shows what a difficult question that is
  18. Now that the new terrain system is in the works and seems to be getting awesome, I would be interested what features are planned aside from the new texturing method... Here is my wish list - more than one terrain. I don't necessarily need a ready-made tiling and streaming system, but the API and the editor should be able to handle more than one terrain per scene - vegetation and object placement. Personally, I will mostly be procedurally place trees, grass, objects etc, so I don't heavily need a terrain painting feature in the editor. Again, the means to place those things via an API or alpha textures would be important for me. - set terrain extensions in the editor (m per pixel, maximum height). If I remember correctly, LE2 had a limit of vertical height of 2000m, at least in the editor) - use externally generated textures (base color, normal map, splat maps) - if possible: define roads/rivers.LE2, you could define e.g. roads using road nodes. Again, doing that via an API would be great - what is planned in the direction of billboarding/impostors/LOD etc. to allow for large amounts of vegetation etc.?
  19. What do you mean by "virtual texturing system" as opposed to splatting? I'm getting a little nervous here, since tools like World Machine give you wonderful splat maps with actual geological meaning (like erosion, deposition etc.) which I would like to continue using in Leadwerks 3.
  20. There's a new option for autorefreshing. true/false in the options dialog, have you checked its setting?
  21. I did a clean install of Leadwerks 3, and now it's working again...
  22. The scene. But I've got UV problems even if I don't modify the model in UU3D and just export it again.
  23. Sorry noob question and not strictly Leadwerks related. I try to use UU3D to scale and rotate some models before importing them into LE. I have some problems with the UV coordinates, materials don't apply to the correct positions in the model editor after exporting the model from UU3D. Now, I have that problem even if I just open my (fbx) model in UU3D and save it again. I know there are some UU3D experts out there, so: Do I have to choose specific export options? Am I missing a step? Please help, thanks!
×
×
  • Create New...