[Daz Studio 4.9?]

Yeah, but I think it's just a $500 license for indie studios or something.

[Hey hey folks!]

Welcome to Leadwerks! I think you'll really like the engine!

 

This is probably one of the best and friendliest communities I've ever seen. It's one of the main reasons why I really like Leadwerks.

[Workshop store feedback thread]

There could be a few reasons (these are just guesses):

 

1. Some items may be overpriced. I love Arteria3D, but $9 for a donkey only usable in one engine seems a little much. IMO, the environment packs are good deals though. There also aren't any videos, just a single screenshot, so I wouldn't know what I was buying (I do because I'm an Arteria3D member, I just bought something anyway to support the engine). I imagine some Arteria3D members won't buy though because they already own the assets.

2. They aren't accessible through the Steam client. I can't even see the prices. So you have to go through the Leadwerks editor. Other games usually don't have Workshop subscribe features built into the game itself, so naturally I think a lot of people just look at the Workshop through the client and see blank pages for the store products. I was thinking this would be how Skyrim tried to do paid mods. It was easy to see what you needed to buy and what the prices were, and you could buy right there.

3. Unlike some of the DLC, the models don't have scripts. Two of the DLC don't either though, although both had pretty good visibility. Is there any data on scripts vs. non-script DLC? I would have been more eager to purchase the crusader if it included a simple AI script.

4. The Workshop items aren't on the front store page of Leadwerks unlike the DLC. If I hadn't been following the blog posts, I wouldn't even know I could purchase anything. Maybe a trailer or a video might help? Obviously, the Workshop items won't be able to have the same visibility as the DLC due to Steam's content display.

5. Also, the same assets sold on Arteria3D's website are like a quarter of the price (includes Leadwerks format as well as additional formats and source assets). I can't imagine that would help with sales.

 

Sorry if I'm being too critical. I really liked this idea and think it would have been great for the engine!

[Normal buffer issues]

Oh I see. Thanks for the link!

[Normal buffer issues]

Oops I read the parentheses wrong

 

What's the point of changing the space if you don't mind me asking?

 

Just to clarify, I normalized the normal without the normalize command because I forgot that was a build-in command.

[Normal buffer issues]

I didn't know they were assigned by default. Thanks Shadmar!

 

Why is the sample coordinate being changed from (0 to buffersize) to (-1 to 2*buffersize-1)? Wouldn't it just be 0 to buffersize for the texel coordinate?

[Offline API documentation tool]

Oh ok. I mean you can still use Doxygen though, that's what it's designed to do. You just put a few comments in your code and the documentation gets generated for you. You can even change the styling of the HTML pages that are generated. There's a few extensions in other languages such as Lua in case that's what you were after.

[Offline API documentation tool]

There are a few different API documentation generators that might work. One tool called Doxygen is nice. It generates linked HTML pages. If you write the function prototypes out, then you can generate the documentation with this. This tool is nice because it preserves class hierachy.

 

But this would force you to write out every function prototype in Leadwerks. You could scrape the Leadwerks API pages though and write the relevant information in a .h file and then compile that file with Doxygen.

[Normal buffer issues]

Yeah I'm normalizing them, but after a certain depth, the normals seem to change a little. Maybe it's due to floating point precision? Either way, I was able to find a workaround by comparing the dot product of adjacent normals with a threshold that changes based on depth.

[Normal buffer issues]

Nvm, I figured it out. The normals start to deviate by more than what I expected, so I added adapting cut offs.

[Normal buffer issues]

I'm trying to make a cel shaded shader and am working on the outline part. Everything seems to work well except for this:

 

http://steamcommunity.com/sharedfiles/filedetails/?id=603858840

 

It seems to me like the normals past a certain depth are not uniform and I'm not really sure why. Or is this just Nyquist-like effect? If so, what would be the best way to handle this?

 

This is the shader I wrote (there's a simple lua script that binds the diffuse, depth and normal textures):

 

#version 400
uniform sampler2D texture1; //diffuse
uniform sampler2DMS texture2; //depth
uniform sampler2DMS texture3; //normal
uniform vec2 camerarange;
uniform bool isbackbuffer;
uniform vec2 buffersize;
out vec4 fragData0;
#define width 2
float DepthToZPosition(in float depth) {
return camerarange.x / (camerarange.y - depth * (camerarange.y - camerarange.x)) * camerarange.y;
}
void main(void)
{
vec2 texcoord = gl_FragCoord.xy/buffersize + 0.5/(buffersize*0.5);
if (isbackbuffer) texcoord.y = 1.0 - texcoord.y;
vec4 c = texture(texture1, texcoord);

//Line Detection
bool edge = false;
float depth = DepthToZPosition(texelFetch(texture2,ivec2(texcoord*buffersize),0).x);
float depth_temp = 0;
vec3 normal = texelFetch(texture3,ivec2(texcoord*buffersize),0).xyz;
normal=normal/length(normal);
vec3 normal_temp = vec3(0);

// Check adjacent pixels
for (int x=-1; x<2; x+=2)
for (int y=-1; y<2; y+=2) {
depth_temp = DepthToZPosition(texelFetch(texture2,ivec2(texcoord*buffersize)+ivec2(x*width,y*width),0).x);
normal_temp = texelFetch(texture3,ivec2(texcoord*buffersize)+ivec2(x*width,y*width),0).xyz;
normal_temp = normal_temp/length(normal_temp);

if ((abs(dot(normal_temp,normal)) < 1) && (abs(depth_temp-depth) > .1)) {
edge = true;
}

}

fragData0 = c;

if (edge) {
fragData0 = vec4(0,0,0,c.a);
}

}

[Workshop store feedback thread]

It works pretty well! Maybe some more scripted objects in the future kind of like some of the DLC, although maybe a lot of users will start making those types of things.

 

I wish I could pay from inside the Steam client and not on the web however. I'm not sure if that's something you can control, but it's a pain having to log in and do the extra authentication stuff (like emailed codes and such) for the web because I generally don't use Steam from there. Also, I'm not really sure what the curated items means on the workshop page and why I can't do anything on those Workshop pages.

 

Overall, great job though!

[Suggestion for a fast Linux PC]

Great advice from above. Just adding on to some of what I've earned.

 

Generally, Intel tends to perform closer to the given clock speed than AMD, so AMD tries to make up for this by adding more cores. Anyway, Intel for gaming is better because of this. AMD is great if you do a lot of video or even photo work though because of the multi threading across multiple cores.

 

Despite that blog post, do not use CoolMaster for power supplies. They are cheap, but they are poor quality. Corsair is the best quality, and brands matter a lot for this component. I learned somewhere that power supply failures can destroy other parts of your computer, so this is something you don't want to be cheap on. I'm pretty sure the GPU and the CPU are really the only two large wattage components (maybe the hard drives as well). There are calculators online to help though. Also, I don't think that a larger power supply is bad necessarily: http://www.tomshardware.com/answers/id-2228533/power-supply-bad.html

 

An SSD/hard drive combo is a good investment. I'm not sure if it will have as much of an impact on Linux machines, but installing the OS on the SSD means faster boot times as well as performance. I would recommend a 128 GB SSD, and at least a 1 TB 7200 RPM hard drive. SSDs do wear down over time (although they don't have mechanical failures like hard drives do), so I would imagine trying to exactly fit everything in one is bad. Also, pick decent brands for the hard drive. I can't remember, but there are a few top brands for this as well.

[Hello, and a question (or two)]

Welcome!

 

1. This is a case by case issue. If the level is small enough sure, but most likely you'll want to import each item individually to take advantage of instancing and occlusion. Note that the heightmap-based terrain uses tessellation, so your terrain mesh wouldn't be able to take advantage of this either.

 

2. This seems like a custom shader, so it probably doesn't exist. You can write one or if you gave specifics on how you want to use the multiple textures, then someone might be able to help you out here.

 

[Model Shadow]

The pivot should also have the same lighting properties. All children inherit the lighting properties of the parent. Maybe this is happening?

[Physics based doors]

I'm going to start over anyway. It's not a bug in the engine, it was just poor implementation on my part because I didn't really know how best to approach it.

 

What I was doing in the past was putting a point in from of the player, and then pointing the door towards that point. You would get instantaneous door movements to point to that point. It also behaves weird if you try to turn your player.

 

Anyway, I just want to know at a high level to achieve this door effect in Leadwerks.

[Physics based doors]

I am trying to make a script for physics based doors (like Amnesia) where you can pull and push the doors. Right now I have slam open and slam closed, but the pull and push are super glitchy, so I think I'm approaching that the wrong way.

 

Any suggestions on how to approach this?

[Decreasing Food / Thirst - Chopping Tree's]

The two health bars idea is good. All you need to do for the decreasing time for thirst is something like this:

 

At the top of your code:

Script.thrist_time=0 --time to keep track of thirst
Script.thirst_max=150
Script.thirst_original=150
Script.location_rate=.0001

 

Put in Start():

self.thirst_time=Time:Millisecs()

 

Put in UpdateWorld():

self.thirst=self.thirst_original-self.location_rate*(self.thirst_time-Time:Millisecs())

 

Then, if you pick up a water bottle, then you would increase self.original by a certain amount (check to make sure it isn't over the max). Change the self.location_rate variable to change the speed at which dehydration occurs.

 

For decreasing health, you could attach it to the self.thirst level (in UpdateWorld()):

if self.thirst<10 then
 --Same logic for decreasing the thirst level (use different variables for health)
end

 

The tree question is a totally separately question though, and can be a bit more involved. I would try getting the first stuff above to work as it might give you more insight into how to do this.

[Basic sneaking tutorial]

What's wrong with the Pick points? The p0 point is the monster's head, in the Crawler's case "self.entity:GetPosition()+Vec3(0,1.6,0)" pretty much nail's it. The p1 point (entity_pos) will be the exact position of the camera (ie the players head).

 

Oh I see. Sorry I kept getting confused with some of the points and stuff for some reason.

[Basic sneaking tutorial]

Yeah sorry about that, I forgot. I usually test for character collision using the closest pick, but you obviously chose to do it a different way.

 

You are right though, the pick position height variable should be switched:

local enemyheight=1.6
if self.entity.world:Pick(self.entity:GetPosition()+Vec3(0,enemyheight,0),entity_pos+Vec3(0,pick_height,0),pickinfo,0,true,Collision.LineOfSight)==false then

[Basic sneaking tutorial]

It should be player.script.crouchheight not player.script.crouchedheight, sorry about that.

[Basic sneaking tutorial]

Nevermind, I forgot that self.crouched and the other variables are for the player. There's a few more steps you'll need to do:

 

Inside of the player's Start() method put this:

player=self.entity

This allows you to reference the player in any script.

 

Next, replace these values in the script above:

self.crouched should be player.script.crouched

self.crouchedheight should be player.script.crouchedheight

self.eyeheight should be player.script.eyeheight

 

That should work.

[Basic sneaking tutorial]

local d = self.entity:GetDistance(entity)
local pickinfo=PickInfo()
--LOS BEGIN
local entity_pos
if entity.script.camera ~= nil then--if there is a camera object
	 entity_pos = entity.script.camera:GetPosition(true)--use the camera position
else
	 entity_pos = entity:GetPosition(true)--otherwise, use the entity's position
end
--cast a ray from the monster's eye to the target position
local pick_height=self.eyeheight
if self.crouched then pick_height=self.crouchheight end
if self.entity.world:Pick(self.entity:GetPosition()+Vec3(0,pick_height,0),entity_pos,pickinfo,0,true,Collision.LineOfSight)==false then
--when we reach here, the target is in line of sight

	 --now we need to check if the target is in the monster's field of view.
	 --we are going to measure the angle from the direction the monster is looking
	 --to the target.
	 local dir_facing = Transform:Normal(0,0,1,self.entity,nil):Normalize()
	 local dir_to_target = (entity:GetPosition() - self.entity:GetPosition()):Normalize()
	 local angle = math.acos(dir_facing:Dot(dir_to_target))

	 --compare the resulting angle in radians, this determines the monster's field of view
local window=Window:GetCurrent()
if angle > 2.0943951 or window.KeyDown(Key.Shift) then --~120 degees
return entity.script
end
end
--LOS END
end

[Raycasting help]

Is there any other code possibly involved? The code you posted seems fine, but there might be an issue somewhere else. I'm not sure what you mean by overflow.

[Basic sneaking tutorial]

This line should be changed from:

if self.entity.world:Pick(self.entity:GetPosition()+Vec3(0,1.6,0),entity_pos,pickinfo,0,false,Collision.LineOfSight)==false then

to

if self.entity.world:Pick(self.entity:GetPosition()+Vec3(0,1.6,0),entity_pos,pickinfo,0,true,Collision.LineOfSight)==false then

 

The closest flag should be true because otherwise the raycast could pick anything on that ray instead of just the closest. Also, the height isn't changing, so you need to account for that.

 

local pick_height=self.eyeheight
if self.crouched then pick_height=self.crouchheight end

if self.entity.world:Pick(self.entity:GetPosition()+Vec3(0,pick_height,0),entity_pos,pickinfo,0,true,Collision.LineOfSight)==false then

 

This will change the height at which the pick will end.