macklebee
-
Posts
3,946 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by macklebee
-
-
Two years on a suggestion that Josh liked, and I am still having to go back to the assets tab to create a new script instead of just creating it with the object's properties tab.
-
1
-
-
The problem is with recast/detour. The navmesh needs certain data like character height/width/stepheight to determine if a path would be feasible, how close a path should be around walls, etc... If you had multiple character sizes then you would need multiple navmeshes - which means characters on different navmeshes would have no knowledge of each other. While I agree that having access to certain variables to control the character cylinder size would be ideal, then it would be an issue with navmeshes and what is passed to it prior to creation. The easiest solution (especially for 90% of users) was to hardcode this. Maybe one day Josh will allow us to control these variables for the controller and the navmeshes, but I would be surprised since this has been requested since LE3 with no luck.
-
This was a long time ago. But I'm having the same issue now,. I worked around it by adding a Math:Random(-0.00001, 0.00001) to one of the movement parameters, this causes it to work. This should probarly get fixed though.
This is not occurring for me at all. So instead of necro-posting a 4 year old post, make a new post with an example that shows your problem. Add details like if you are using the beta or an older revision, are you using a custom script that controls the controller, etc...
-
I never really understood the inherent env shaders as it puts the cubemap against the emission channels for FragData2. Seems like it should be put against the diffuse color components of FragData0. Here is a shader that does this - and honestly at this point i don't know where I got it...
diffuse+normal+specular+cubemap.zip
I used the inherent glass textures for the diffuse, normal, and specular texture slots. I put the skybox texture as slot 4, set the blendmode to Alpha, and set cast shadows, two sided, depth test, depth mask, and z-sort to true.
-
3
-
-
I try to not parent anything that doesn't have the scales set up correctly to (1,1,1). It seems there is always something that is going to cause issues with rotation or positioning if you have multiple things scaled especially if you are setting the rotation/position to local space.
As far as child scripts, I just keep in mind that its parent and its parent's parent - all the way to the base parent, must have a script. So far that approach has worked for me.
But in attempt to make this even easier and to avoid any scaled positioning/rotational child issues, this whole assembly could have been one prefab without the need to load another prefab onto it. But I understand your reasoning for it, since you are going to use the same candle flame effect on other items other than the chandelier.
-
2
-
-
It may be failing to load a map. Delete your 'leadwerks.cfg' and then try starting the editor again.
Edit- also, attach your 'leadwerks,log' because it looks like there is another error referring to '...target entity not found'
-
The only time I see this is when I load the chandelier prefab via code. If the chandelier prefab is in an editor scene, then it loads everything fine. Is this what you are doing?
Edit-- I went through and fixed the scale on all the candles, candlesticks holders, and the chandelier by opening them in the Model Editor and using Tools>Collapse to set the inherent scale to (1,1,1). Then I rebuilt my chandelier with the candlesticks and added a slightly modified version of the 'LoadCandleFlame.lua' script that makes the flame a child of its candle. Also, my flame is a scaled sprite prefab of the firepit fire and point lights so i had to change slightly the Y positioning of the Flame in the script. Now whether I load the chandelier via the map or load it via code, it loads, runs the scripts, and positions the candles' flames properly.
'LoadCandleFlame.lua' was modified so that it only needed to be attached to the chandelier model itself. Also, note that I didn't use the 'Candle_02.mdl' as its origin was offcenter from the model after fixing the scale.
function Script:Start()
local candle = "Candle_0"
local numberofkids = self.entity:CountChildren()
for j = 0, numberofkids - 1 do
local y = 0
local child = self.entity:GetChild(j)
local pos = child:GetPosition(true)
local name = child:GetKeyValue("name")
local Flame = Prefab:Load("Prefabs/Props/CandleLight.pfb")
Flame:SetParent(child)
if name == candle..1 then
y = .16
elseif name == candle..3 then
y = .19
elseif name == candle..4 then
y = .23
elseif name == candle..5 then
y = .26
end
Flame:SetPosition(pos.x,pos.y+y, pos.z, true)
end
end
Granted all of this could be just turned into one prefab instead of building onto each other...
-
1
-
-
Is your 'brick' made from a CSG brush in the LE Editor? If so, review the "Painting Brush Faces' section of the Materials tutorial.
http://www.leadwerks.com/werkspace/page/tutorials/_/materials-r7#section6
-
its very odd. what is really weird is that the branches' shadows show movement but the actual branches do not.
-
The modeling application you use or its export options will affect the vertex colors. If you are not using the vertex colors for anything else, then just open the model in the LE Model Editor and use the Tools>Strip Vertex Colors option and it will make all vertex colors white (1,1,1).
-
Pictures are nice but an example model and script showing the issue would be more helpful.
-
Seems to work ok for me - maybe I am not seeing the issue you are referring to? Other than the warning about 'ex_texcoords0' and 'ex_normal' might be used prior to initializing, I am not seeing a problem. Do you have a particular item where the normals seem wrong?
To get rid of the warning, just initialize the variables prior to the for loop:
void main() {ex_texcoords0 = vec2(0);
ex_normal = vec3(0);
for(int i = 0; i < gl_in.length(); i++) {
gl_Position = gl_in.gl_Position;
ex_color = g_ex_color;
ex_texcoords0 = g_ex_texcoords0;
ex_normal = g_ex_normal;
EmitVertex();
}
EndPrimitive();
...
...
-
Didn't leaves used to sway depending on the color of the vertex? Not sure if that's still the case but that's what I'd try first (in addition to checking the stuff macklebee suggested above).
Well, looking over the wind calculation they still move based on vertex color and maybe that is his issue. But Tomas has not said whether or not his problem with lack of movement occurs when he is manually placing the tree or when using the vegetation tool. If he is manually placing the tree, then the leaves will not move based on the inherent 'Models/leaves.shader'. If they are not moving when the tree is set using the vegetation tool, then it very well could be the vertex color that is preventing the swaying.
//Wind animation
float seed = mod(currenttime * 0.0015 ,360.0);
seed += ex_entitymatrix[3].x*33.0 + ex_entitymatrix[3].y*67.8 + ex_entitymatrix[3].z*123.5;
seed += modelvertexposition.x + modelvertexposition.y + modelvertexposition.z;
vec4 movement = vec4( vec3( (vertex_color.r) * vertex_normal * 0.02 * (sin(seed)+0.25*cos(seed*5.2+3.2)) ),0.0);
modelvertexposition += movement;
modelvertexposition = entitymatrix_ * modelvertexposition;
But again without seeing the model, its all just a guess.
-
1
-
-
The only time I see leaves swaying is when the tree is set with the vegetation tool. If I set the same tree by just placing the model, I get no leaves swaying. The 'Models/leaves.shader' doesn't have a wind animation calculation in the vertex code, but the 'Models/Vegetation/leaves.shader' does. So that at least explains that, even though I think that needs to be rectified inside the 'Models/leaves.shader'.
As for the other issues with shadows, without seeing the model in question we can only guess. Perhaps you need to recalculate your normals? Faces are flipped? Maybe you don't have the material settings the exactly the same? I know I mess up trees' shader setting all the time because for some reason the default LE shaders are all named the same but are only differentiated by what folder they are in... ie. there are 3 'leaves.shaders' but the one in the vegetation folder can't be used for shader 0 but only for the vegetation shader 4.
-
1
-
-
I lied to you!
It looks like Josh has added that at some point but doesn't have it documented yet. I can see from a lua global variable dump there is this command:
Math:SeedRandom(float)
EDIT-- just tried it and it appears to work properly. I get different numbers each time i run the program.
-
2
-
-
Usually, when a program starts, it initializes the generator with a fixed seed. That means that, every time you run your program, it generates the same sequence of pseudo-random numbers.
]LE's Math:Random() doesn't have a way to change the seed.
-
Just as an aside here - but Julio is not some random guy that has no experience with any other physics engines other than his own. He was (possibly still is) one of the main physics programmers for Planetside2 multiplayer that uses PhysX. Point being - the guy knows his sh.it.
http://www.metacritic.com/person/julio-jerez?filter-options=games
http://www.mobygames.com/developer/sheet/view/developerId,7571/
-
2
-
-
updated for latest beta:
-
1
-
-
The screen is not being cleared each update. It would help if we could see the code you are using for your main loop or any script that may be drawing to the screen.
-
2
-
-
Its due to trying to Release() something twice...
function Script:RemoveNums()
for i = 1, #self.NumPrefabs do
self.NumPrefabs:Release()
end
end
function Script:MakeNums(num)
for i = 1, #self.NumPrefabs do
if self.NumPrefabs ~= nil then
self.NumPrefabs:Release()
end
end
...
...
Releasing the sprites did not make them nil. So just change the code to:
function Script:RemoveNums()
for i = 1, #self.NumPrefabs do
self.NumPrefabs:Release()
self.NumPrefabs = nil
end
end
function Script:MakeNums(num)
if self.NumPrefabs[1] ~= nil then self:RemoveNums() end
...
...
...
-
-
Well it depends on how you are planning to do the blending inside your modeling app - by a fixed amount or via a mask/map. Based on the pics you posted, I would assume you will have some sort of mask/map that determines what texture is visible? If so, its a fairly straight forward shader where you draw the two textures based on the color of the mask texture.
EDIT -- if doing a mask map, here is a quick version of a model shader that blends two diffuse textures based on the mask map's alpha: blend.zip
-
4
-
-
Just added the missing cubemap uniforms and code to an animated model shader and appears to work ok. Just add this as the material's shader and add a cubemap texture to the material's texture5 slot.
diffuse+normal+specular+env.zip
Edit- granted you could just use the normal model diffuse+normal+specular+env.shader for the material as well if the helmet is just an accessory to the animated model. If the helmet is a standalone model, you could always just parent it to the animated model's head bone.
-
2
-
-
That script posted in that blog is a WIP that is missing alot of features that its supposed to do - no check of team ID, no occlusion check, no rotating the turret... etc... Again, without an actual example or code to try, it makes it hard to troubleshoot.
Edit-- I assume you are using the updated code shown here? http://www.leadwerks.com/werkspace/blog/1/entry-1673-building-turret-ai-part-2/
And if that is the case, then it performs a pick that may not see an enemy. Your example 'gif' has everything ontop of each other. Try spreading the turrets out and put the targets in the center to see if this helps your situation. Also note what Josh posted at the beginning of the blog:
"To avoid overloading the engine I am only performing the visibility test at most once every 500 milliseconds. This provides near-instantaneous updating while preventing the picking from becoming a bottleneck and slowing down performance."You may need to increase this time if you are performing so many picks.
-
1
-
Question about creating vegetation
in Game Artwork
Posted
burgelkat - thats the difference. Nice catch.
In the two leaves shaders that use the wind calculation (vegetation & vegetation shadow), the code is slightly different between the two.
Shaders/Vegetation/leaves.shader:
Shaders/Vegetation/Shadow/leaves.shader:
The Shaders/Models/groundplants.shader code also looks like the vegetation shadow code. I am not sure why it appears to work on some trees and not the others (an issue with vertex normals/color?). But if you change the code to '1.0-vertex_color.r' then it appears to work fine on his pine tree.