-
Posts
421 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by Rastar
-
-
Model::GetSurface(index)
Vec3 Surface::GetVertexPosition(index)
Surface::SetVertexPosition(index, Vec3 newPos)
should do the trick. Of course you'll need a way to identify the indices.
-
Maybe an environment cubemap?
-
I have to mingle in here as well. I have no problem with the Ouya being ditched in favor of SteamOS, that's a sound decision. However, simply dropping both mobile platforms is not acceptable. Up to now I was under the impression that they will be ported to 3.1, only at a later stage (remember Josh's experiments with a deferred renderer for the iPad?). Just a little over a year ago Leadwerks put its focus on mobile (and drove some veteran members of the community away with that decision), only to drop that again now and go for Linux? I understand this is a one-man show, but changing course that easily and often is not the solution. I mean, many of us (me included) will probably never get a game out of the door, but even if we tried we couldn't because during the two-year-something development time the engine would have changed at least twice with support being dropped for the engine we started with.
Don't know if I'm sad, angry or disillusioned. All of them I guess.
- 2
-
Which means: We really need some more information what the difference between those two version is before we can state our preference. To me the most important questions are
- What are the supported publishing paths for the two editions?
- will there be any differences feature-wise (apart from the obvious tighter integration with the Steam workshop)?
- differences in release cycle (e.g. always Steam first, stand-alone next)?
-
No, pretty sure the shaders couldn't be used, only the textures.
-
Don't know if Josh's opinion on this has changed, but just FYI: There was a discussion on this back in the LE2.x days:
http://www.leadwerks.com/werkspace/topic/5750-le-with-substance/page__hl__substance
-
One slightly insane sounding idea would be to release source code for the editor - free of charge to licensees. That way Josh wouldn't reveal any of his IP regarding rendering etc. but really could jump-start community contributions. I guess many of us don't want to fool around with the core engine but would love to improve the workflow, deal with a few UI bugs, inconsistencies and omissions. And I think the only way to stay afloat in these crazy times is to 1) have a few differentiating factors and 2) leverage the community for development and content.
Just a silly thought..
-
Well,
"We only require your soul."
"The last tweet was supposed to be amusing, not factual. Following this account requires at least Level 10 in sarcasm detection."
It's a joke (and a good one). Pity, would've loved to take a look at their terrain implementation
-
Yoy should be OK here. The license conditions state that
a) You need a Pro version (regardless if it's Indie Solo/Enterprise or Enterprise) to use the models and textures shipped with the product (and asset packs) commercially.
B) Everything you do with FP is your own IP.
At least that's the way I understood it
-
You could also try http://www.hptware.co.uk/forester.php. It's not free, but very affordable, and the poly count is fairly low.
-
Oh, sorry, was assuming 3.1. For 3.0 you will need a shader with a correct alphatest. I can't find the link to shadmar's 3.0 tree shader. Basically, in your fragment shader you will need the line
if (outcolor.a < 0.5) discard;
and a "Solid" blend mode (I guess you're using "Alpha" right now?)
-
Try assigning an alphamask shadow shader (Shader->Model->shadow->shadow+alphamask.shader) in the material editor.
-
Actually, there has been something similar for Leadwerks 2.x (I think it was simply called "the Leadwerks community project). I wasn't part of the team at the time, but looking from the outside I think both sides were benefiting from it, and it seemed to influence Josh's priority list. So, in short: I actually think this is a very good idea!
-
Well, those shadows fade out when I move some 20 units or so away - that's a pretty short range for an (inifinite) directional light... it definitely has to go further, and it has to be adjustable.
- 2
-
Sorry for necroing an old thread, but... has this been solved/answered? The range setting on the lights tab doesn't do anything (and by the way, if you close and reopen Leadwerks, that range is set back to -150/150, even if I save my map before closing). Also, I actually don't understand what those values mean, especially the first one - is that the range of objects behind the camera that cast shadows?
-
Maybe try to delete *everything* include Leadwerks' .meta files, fbm folders etc. As wrote, for me it suddenly worked (bu manual assignment), but i don't know what was different.
-
Mmmh, I started over by deleting everything and copying the files freshly into the Leadwerks folder. The automatic assignment didn't work for me, but that be because the file paths are different (at least the DAE files reference textures in an "images" folder, but the the distribution stores them in a "textures" folder that I copied over).
Now it's working , but I don't think I've done anything different than the first time.
Anyway, thanks for your help!
-
As a 3D modeling analphabet I need a little help here...
I am trying to import some tree models from pure3D's Vegetation Starter Pack. As usual for trees, they have at least two materials (for trnk and leaves), sometimes more. Now, assigning those two materials for the beeches in the pack (using drag 'n' drop in the model editor) works fine, but e.g. fails for the oaks: any material will always be applied to the whole model.
What puzzles me is that those trees look similar in structure when viewed in UltimateUnwrap3D, and I don't really know what Leadwerks is looking for to identify a surface. I *could* export the materials/groups as separate meshes, but I don't really want to do that.
Any ideas what I might be doing wrong or can change to make things work?
-
A bit of documentation on this would be helpful, I find this bit confusing as well. E.g., I have to assign a alphamask shadow shader to my trees so they correctly cast shadows, and I actually don't have a clue why.
- 2
-
I actually haven't looked too deeply at the Leadwerks terrain system, but this is "just a bit of shader magic". Quickly scanning the terrain texture shader, it seems there are certain thresholds for the texture blending, resulting in those hard edges. So tweaking the shader might give what you want. You could also try and play with the "transition" slider on the material layer page, maybe this improves things towards your goal.
-
Actually, I think this is looking much better and more realistic than the typical texture blending using alpha values. I mean, for ground structures such as this you have small height differences that determine which material is on top: The sand will fill the lower parts of the rocks and be completely absent at the top, and not gradually shine through the rock texture. For example, there is a very popular terrain add-on for the "he-who-must-not.be-named" engine that specifically uses heightmaps for terrain textures to achieve this effect.
EDIT: By the way, now "mrstralberg", Sir? Being more formal these days ;-) ?
EDIT2: There was a post where Josh discussed this http://www.leadwerks.com/werkspace/topic/7196-terrain-texture-with-blend-pattern-in-alpha/page__hl__alpha
- 1
-
If you specify that variable as "in vec2" it is supposed to be a vertex attribute, ie have a different value per vertex. However, the Shader:SetXY() methods set shader uniforms. So I guess, in your case you should define that as
uniform vec2 my_offset;
-
The fragment shader might work on pixels, but everything before it works on vertices. You define vertex colors in your modeling program, and they are interpolated for the fragments by the rasterizer, just like everything else.
I don't think LE should provide tools for vertex coloring, that's really the domain of DCC tools.
-
Not sure if I'm misunderstanding you, but that should be possible already. Leadwerks passes the vertex color already go the shader (uniform vec4 vertex_color). By default it is mixed into the diffuse color, but the shader could use it for something else.
Of course, you would have to define the vertex colors for your model in your modeling program first.
3.1 Non Steam Download
in General Discussion
Posted
I'm having the same issue. Now I was a Kickstarter backer for Indie Edition ($100). To my understanding that entitles you to an update fron 3.0 to 3.1 (which makes some sense since it's the same amount as the update fee). My guess is that at least my problems have something to do with that. Either the updater doesn't take those cases into account, or I was wrong about that update thing.
In any case, this corrupted my 3.0 installation, since it updates all project and content files but not the engine itself.