Rastar
-
Posts
421 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by Rastar
-
-
Thanks for checking! I have just watched that video on another computer and my iPad, and I can't see the described artifacts either! However, I can still clearly see them on my PC either when playing the video or running the map inside Leadwerks. WTF? I tried taking a screenshot but that doesn't show them as well.
Must be some issue with my hardware or driver.
-
After some time off I created a new project today (C++ standlone build 3.2). I just build it and ran it with the start.map to see if everything was fine, bt I got heavy artifacts when moving the camera:
If you look closely you red borders around the bottom orange box, the edges of the concrete box flickering and the edges of the concrete box getting a yellow tint, the sides changing with camera direction.
Bug, feature, my mistake?
-
True. But the means for many of the things that you describe are already in place. You already *can* write post processing shaders, for example (of course you must know how). But you can't write plugins or something similar right now. The things I had in mind when I asked that question were a road generation tool, procedural placement of vegetation and a custom material/shader editor. I just think the main focus for a one-man show like this should be to enable its community whatever they want to do - that's the only way you can make up for other engines' man power. But I know that this discussion is leading nowhere...
-
Too bad - that basically means there is no way to procedurally modify your levels at design time. I think that should be high on the priority list, either by adding Save() methods to the Leadwerks API, or by allowing Lua scripts to run in the editor.
-
Bumping this thread since I'm reallyreally interested in an answer...
-
I had a quick look through the programming book on Swift, and I think it is a very nice language. It borrows lot of ideas from many other modern languages (especially functional ones). Very compact syntax (yes, type inference, but it's still strongly typed), higher-order functions, closures, pattern matching. Also some nice addition that reduce the shortcomings of typical OO languages (e.g. protocols that can be extended to existing classes). I haven't looked at concurrency in Swift yet, but since it's more immutable and functional in style, that should work pretty well.
Does the world need Swift? Definitely not. If you're on a platform besides iOS. There are languages like Scala and Clojure for the JVM e.g. that are similar or even more powerful. But if you're programming for iOS you should definitely use Swift. You're bound to the platform anyways, and Objective-C is really ancient, with a horrible syntax, I can't see a reason not to use Swift for this use case.
-
I would like to manipulate several Leadwerks assets outside the editor. The API provides all necessary functionality, except saving. I've seen that there is a Save() method e.g. in Map and Texture, but they are commented out. Also, the Object base class has methods for serializing/deserializing which require a Stream (and I'm unsure how to correctly create that).
Long story short: Is there currently a way to save such objects (as a first step I would need materials and the map itself)? @Josh: If not, could you add that?
-
Well, Rick seems to be quite proficient in it :-) Smaller things I might be able to do as well.
-
You will probably have to recenter everything to the origin (read: the player) anyway for an "endless" terrain, because beyond a certain distance (say, 16000) physics will get unreliable due to floating point inaccuracies.
-
What exactly is the issue of setting the OpenGL contexts? That shouldn't be language-dependent. By the way, I found that using a library like http://www.glfw.org makes this process rather painless, cross-platform (and C++ based). There, setting the initial context for OpenGL requires a
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3); glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 2); glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE); glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
So you have to set the profile to 3.2 and forward compatible, which was a little counter-intuitive to me :-)
As a side notice, I find the statement "I don't have time for that" a little...nonchalant. OSX users have purchased/preordered the upgrade like everyone else, and I guess that "contract" should be fulfilled even if other things seem to be more in focus right now.
-
The LE3 displacement shader already tessellates, but probably the algorithm and its configurability could be improved upon (as Josh stated above).
And yeah, that tessellated terrain is nice, but it's a pretty complicated algorithm (described in Shader X7), since they first render a point cloud in a first pass to get info on the terrain structure, and then calculate the tessellation factors in a second pass.
-
Actually - no, I don't (maybe shadmar and klepto know something?) It might be better to start with a forward renderer to learn shader programming, because everything is right in front of your eyes, and playing around with different light types, lighting models etc is possible. I started digging into shaders with Leadwerks 3.0 (which has a forward renderer), and that was helpful at least for me. And it might be easier to understand what is going on in a deferred renderer if you have done everything for yourself first.
-
It means a lot of effort has gone into the Linux branch (for good reasons) that could otherwise have been spent on the core engine (yes, bug fixes, new features). And once again, it makes perfect sense for Josh to focus on Linux, I would probably do the same if I were him (and I backed the Kickstarter campaign). But if I wanted to publish a game in year or so (if I really had the capability and time to do that) I'd be hoping to publish to the major markets: Windows, iOS and Android (for which support has been dropped) and MacOS (which seems to have moved out of focus a little as well). Linux would be a nice to have (and, at least for me, the possibility to publish on Linux would be sufficient). More important for me would be improvements in performance, stability and capability of the engine itself.
This is completely subjective, and I didn't want to sound negative. I'll continue Leadwerking, I'll still be here, just somewhat less often.
-
1
-
-
Don't get me wrong - I fully understand the strategy, and it makes a whole lot of sense. And a Linux editor is of course an essential piece of the picture. It's just that my personal priorities have a different weight.
-
I've received another Kickstarter post by Josh yesterday, giving an update on the status and outlook for the future. Its main message seemed to be that the "Linux in and out" will be the focus for the next year, and I must confess that I am not too happy with that. I can understand that strategy from Josh's point of view - especially with the recent changes in the game engine landscape he has to find his niche and excel there - but this is going in a direction that is of minor importance to me. Linux is an interesting target platform and might gain some market share (although right now that is just a hope, not a safe bet), but publishing to Linux would be sufficient for me, and I'd rather keep the mobile targets than a Linux Editor. And the development of features for the engine in general has almost come to a halt in the last couple of months. Actually, the community initially had voiced some concerns about "going Linux" due to Josh being a scarce resource, and the answer was "the Linux port will be done by somebody else, I'll focus on the core" but it doesn't seem to have worked that way.
Well, long story short: I'll probably have to refocus a little myself. The good news is: Fewer boring tessellation posts! And I'll definitely hang around and see how things are going.
-
It's not working for two reasons:
1) All those special variables for vertex normal, light position, transformation matrices are not part of GLSL. They are passed in by name by the engine, and every engine has its own naming convention. If you have a look in a Leadwerks shader, the uniforms there have names like vertex_normal, entity_matrix ('M' of the model-view-perspective transform) and projectioncameramatrix (the 'VP'). So the variables you're using in your code don't carry any values. But even if you used the Leadwerks variables, this concrete shader wouldn't work in Leadwerks 3.1 because
2) it's written for a forward renderer, and Leadwerks 3.1 has a a deferred renderer. In a deferred renderer, the lighting calculations (here the diffuse shading with the NdotL term) are done for you behind the scenes. The shader's main job is to fill the fragData G buffers for diffuse color, normal, emission etc. that the engine needs for its calculations.
-
1
-
-
I faintly remember Shadmar doing something like this in the early 3.0 days..
-
I am not too familiar with the various raw formats (I think every manufacturer has one or even several variants containing some specific metadata). And I don't know if Leadwerks is able to skip this metadata. A "really raw" RAW file for heightmap import contains just the pixel values (only one channel) as floating point values (preferably is 16bit format, or two bytes per pixels). Maybe you can convert the file using Photoshop or a similar tool? Or you could write a little conversion routine.
-
Ah, there's one glitch: The maximum tessellation factor is 64, so you won't be able to e.g. tessellate one large BSP face into thousand of triangles per edge.
-
This somehow reminds me of a blog about the abuse of tessellation in Crysis 2 :-)
http://techreport.com/review/21404/crysis-2-tessellation-too-much-of-a-good-thing/2
An idea might to include the displacement map resolution in the calculation of the tessellation factors: Check how many pixels would lie on the edges of a patch and tessellate accordingly (of course lower those factors depending on viewing distance). I was planning to use something like that for my terrain experiments.
-
This is one of the first things I'd do if Leadwerks had an editor plugin system - a general tool for placing splines and an extension that extrudes or generates a geometry along those splines. For the "megatexture baking" option that Josh mentioned we would of course also need to be able to programmatically alter the heightmap and modify the texture. Come on Josh, set the community on fire :-)
I'm not sure if the texture baking works in all cases, though - only for very high resolution terrains, I guess (like 1m per px or so), because otherwise the heightmap couldn't be modified to include the road geoemtry, and the road shape would follow the bump and dents of the terrain. It did in LE 2.x, actually, and I never liked that. In those cases a mesh might still have to be placed on top of the terrain, but the baked texture could still be used for rendering the road for higher view distances.
-
Any action needed on our behalf?
-
Shadmar's code expects a dffuse detail texture in the "Texture 4" slot, which is empty in your screenshot. If you want to use the base diffuse for this, change the code to
outcolor *= texture(texture0, ex_texcoords0*4.0);
EDIT: I probably misunderstood your setup... You want to use the cliff texture as the detail texture, right? And in your screenshot, are you using shadmar's code for that very texture?
-
2
-
-
I am referring to this post
Unter "Exemptions" it states
"Leadwerks 3.0 customers who backed the Leadwerks for Linux Kickstarter project for $99 or more will receive the 3.1 upgrade for free."
So that's pretty definite. But then, it also says "There is no purchase necessary to upgrade the mobile add-ons from Leadwerks 3.0 to Leadwerks 3.1"
As I said, my guess is that the updater currently isn't aware of all those different cases.
-
1
-
Using exported GLSL shaders from Blender
in Programming
Posted
If you open those files inside Leadwerks, it will parse them and correctly categorize the shader parts (vertex, fragment etc)