-
Posts
3,946 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Downloads
Everything posted by macklebee
-
The category selections have never worked for me but I can still select a game and launch it.
-
It is probably still in your software library, so you can install it from there. To help with your eyesight and how I fixed the above issue: 1) Changed software view to Grid 2) Move Slider to max Zoom 3) Right-clicked on software and chose 'Delete Local Content...' 4) Re-installed
-
Yes, if you are using probes, you will need to hide the triggers in the editor prior to performing the GI option.
-
Is this a global setting or per texture?
-
The inherent caulk material located in the Materials/Developer folder provides this function. I changed the blend mode of the material to be able to see through it within the Editor.
-
I scaled it in UU3D using 3D Tools>Modifiers>Scene>Scale To... before exporting as well. The Model Editor for whatever reason strips vertex coloring with certain options - like Collapse. Since the scaling references are the same in UU3D and I want to avoid parent/child related issues with scaling in LE, I just always use UU3D as a final check for size, UVs, animations, etc prior to saving as MDL. As for the issues of textureless materials, it doesn't appear the auto conversion knows what to do with that. Granted if its textureless, you can always just convert to vertex coloring or just make an LE material to apply.
-
The GI looks better just because it gives depth to otherwise flat looking objects that are in "shadows". This has always been an annoyance with LE's dynamic lighting vs baked light maps since anything not hit by a light doesn't show normals. The GI solution is good remedy for this. Out of curiosity, has anyone done a large indoor scene with LE's GI? Any problems with performance due to this?
-
Physics is getting very heavy on my model.
macklebee replied to psygnosys's topic in General Discussion
Looks like maybe you need to reset the transforms on the collisionmesh/crane mesh prior to exporting? Even if that fixes it, that still seems to be a fairly detailed physics mesh for something thats going to be static. Seems like the better solution would to just make simple block primitives. Maybe even just create simple 'caulk' textured box primitives in LE as the physic shapes and create a prefab? -
If you are referring to vertex colors then the auto conversion doesn't seem to allow for it. But if opened in UU3D and perform 3D Tools>Vertex Colors>Convert..., Select All Materials, and then convert, it will transfer your textureless materials to vertex coloring. Save to MDL with vertex color option checked. Edit - Since LE doesn't really have "phong" materials, you wont get that backlit/rim lighting on the model. You could attempt the "PBR" like shaders/materials in the workshop or try to use the probes to get similar results on a static object. Also, if you want more control over specular, then I would suggest using textures/materials in LE.
-
Not sure what "looks wrong" means. Have you tried calculating the normals or flipping the normals? Are you referring to the numerous surfaces or children meshes?
-
A quick and dirty way is to make a copy of the object, scale it slightly larger, and flip its normals. Script.highlight = Model:Load("Models/crates/crate_large.mdl", Asset.Unmanaged) function Script:Start() self.highlight:SetScale(1.01,1.01,1.01) self.hmat = Material:Create() self.hmat:SetColor(0,1,0,1) self.hmat:SetSortMode(true) self.highlight:SetMaterial(self.hmat) self.surface = self.highlight:GetSurface(0) self.surface:FlipNormals() self.highlight:SetPosition(self.entity:GetPosition()) self.highlight:SetParent(self.entity) end A more complicated way involves rendering to another buffer/world, performing an edge-detection/cartoon post process shader on the scene, and then drawing the results to your main world. Edit--Doing the quick and dirty way looks pretty decent once you set the zsort to true on the flipped material.
-
Yes it scales just fine. But to avoid the problems that come with a scaled object that is going to be used as a parent to another object, I would strongly suggest people figure out their modeling app to leadwerks scaling or worse case use the LE Model Editor's scale/collapse to get the working model's scale as 1,1,1.
-
Are you asking what CSMs are? https://msdn.microsoft.com/en-us/library/windows/desktop/ee416307(v=vs.85).aspx
-
Hard to say without seeing the model in question, but i would warn people to avoid scaling models via code or through the scene's object properties. If you cannot get the modeling app-to-leadwerks scale figured out, then I would suggest using the LE Model Editor to scale to the size you want then collapse the model. This should set the model's scale to 1,1,1 for use in game. Note this only works with non-animated models. If you collapse an animated model, it removes the animations/bones.
-
You have to look at each stage with ranges in meters. Try this script attached to your directional light to see the affect of changing the stages' ranges: function Script:Start() self.value = 5 end function Script:UpdateWorld() local window = Window:GetCurrent() if window:KeyHit(Key.Up)==true then self.entity.shadowstagerange[0] = self.entity.shadowstagerange[0] + self.value self.entity.shadowstagerange[1] = self.entity.shadowstagerange[1] + self.value self.entity.shadowstagerange[2] = self.entity.shadowstagerange[2] + self.value self.entity.shadowstagerange[3] = self.entity.shadowstagerange[3] + self.value end if window:KeyHit(Key.Down)==true then self.entity.shadowstagerange[0] = self.entity.shadowstagerange[0] - self.value self.entity.shadowstagerange[1] = self.entity.shadowstagerange[1] - self.value self.entity.shadowstagerange[2] = self.entity.shadowstagerange[2] - self.value self.entity.shadowstagerange[3] = self.entity.shadowstagerange[3] - self.value end end function Script:PostRender(context) context:SetBlendMode(1) for i = 0, 3 do context:DrawText("Range: "..self.entity.shadowstagerange[i],2,i*22) end context:SetBlendMode(0) end
-
Its exposed to lua - see the script i posted in the link above. Whether or not its exposed to the game launcher app depends on what build the launcher is made from and if it was exposed in that version.
-
You may have to adjust the stages' linear offset as well if you modify the stage's range. See here for a script that allows for modifying the linear offset in game to help remove artifacts: http://www.leadwerks.com/werkspace/topic/14985-changing-shadow-resolution/#entry101390
-
try minimizing/maximizing?
- 1 reply
-
- 1
-
That's what we all have been saying as well - the gun just needs to look like its pointed in the right direction. You can do a pivot/point but honestly i didnt see much difference. So as long as the gun is positioned/rotated to look like it could make that shot, then the player will be no wiser that the pick is coming from the camera and not the end of the gun. Not that the end user cares - they just want the bullet to hit where they aim.
-
Just rotate the gun to point towards the center. Do the pick from the camera to the center where the crosshair is at, The bullet still comes from the gun and will hit at the crosshair. As long as the gun is rotated to in the direction of where the crosshair is at, no one will notice. FSPGun.lua: --if self.entity.world:Pick(bullet.position,bullet.position+travel,pickinfo,0,true,Collision.Projectile) then -- below replaces this in Script:Update() if self.player.camera:Pick(context:GetWidth()/2,context:GetHeight()/2,pickinfo,0,true,Collision.Projectile) then
-
In my first image its just rotated towards the center of the screen but not constantly rotating - granted this will only give the results you want within a certain range. In the second image, the player is not aiming with ironsights but he is holding the gun at the center of his body - much like you would do if holding the pistol with both hands (which the fpsgun prefab is doing). Its all a matter of preference. Your second image would basically require two picks - one from the camera to hit point, then from gun to that hit point.
-
-
The shot is going where the gun is pointed. You can pick from the camera view if you don't like that or you could just rotate and position the gun to shoot at the spot you want. If you use the gun's position/rotation then it would also incorporate the small sway and bob that causes the minor offsets in the bullet impact. The current fpsgun script is picking along the gun's axis. So if you want that, then try changing in the prefab setup to something that works: Script.offset to 0,-0.17,0 Script.rotation to -29,-6,0 But then you might not like the look of the gun in the scene, so at that point perform the pick from the camera.
-
I must be doing something wrong because i see no difference after updating my project. Its hard to use something that doesn't get implemented. I have had a decent glass shader for a couple of years but no reason to use it when it looks weird with black or no shadows. But I will take what i can get if textures on lights work!