nick.ace

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.

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?

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.

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.

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.

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

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); } }

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!

I agree with cassius. I like the rename of Indie Edition, but why not call the Professional Edition something like Leadwerks Game Engine: C++ Addon. With other pro editions for other software, professional usually includes extra support, more features, sometimes even a different license. Just my 2 cents

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.

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

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.

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?

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.

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

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

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

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.

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

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.

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.

Does the barrel have mass or a physics shape attached to it? You could be spawning in a new barrel like you described, and it looks like one because it is in the same position. http://www.leadwerks.com/werkspace/page/tutorials/_/scene-panel-r3#section2.3

Yeah, just add another condition to it: --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 You may even want to put the sprint detection code somewhere else under different conditions, but you'll need to decide what you want.

This does exactly what Josh said (with video tutorial): http://www.leadwerks.com/werkspace/page/viewitem?fileid=364622139 BTW, I don't really have time to expand this, so if anyone wants to contribute, let me know and I'll make you a collaborator.

Edit: This code is untested, but should work based off of Josh's code.