Daemoc

I remember now. It was in the model editor. Under the tools section. For some reason it was auto selecting "fit" rather than "scale". Just select "scale" and set it to 100%. Another odd thing I found was the import process was expecting centimeters and auto-scaling to meters. As a result I had to export everything at 10% for the scale to be correct at 100% in the model editor. I was using .FBX but I was not using blender though, so the last part might not apply to you.

You might want to check and make sure the editor is not auto-scaling the model after import. I had this same issue, and if I remember correctly, it was the game editor itself re-scaling the model. It has been so long since I have messed with this I can not remember where the setting was, but the fix was in the editor. Somewhere in the model properties if I recall.

https://www.leadwerks.com/learn?page=API-Reference_Object_Context_DrawLine But yes, the link is broken.

I am way behind schedule, but progress is being made... The gun barrel and hammer need a texture tweak, they are too dark. Although not as dark as they appear in this gif, they still need some light. Even though you will never see this up close, I wanted to go for realism. I spent a lot of time on the grip. Again going for realism here, but also want to make it interesting. I took a basic Weaver stance and added a little dynamic flare. Things look better a little exaggerated. Especially at this small scale. Almost ready for prime time.

I reduced the number of polygons of the test pistol considerably. I am just under 850 tri's including magazine. It also has the usual hand painted bumps and texture using Photoshop, then baking in GI lighting. This is an odd way to create textures, but it is quick and the results are sufficient for the game style. The screen shot below is a 100% GL Viewport image, not a render. I still need to paint the rotating barrel lock, but other than that it is done. This is ready for animation, export and in game testing. I hope I can have it in game tomorrow by the end of day.

Here is the grid snap in action... Grid System Vid This is a 64cm grid size and proper scale models at the moment. This is the current plan, but that size may change. I am still stopping the character short of the destination as I can not stop the deceleration. Anyone have any ideas here?

Thanks carlb. We have not fixed the deceleration yet, but we have the grid snap working. Not only working, but working exactly as we wanted.? We almost gave up on it yesterday, but once the code "clicked", it was actually quite simple. We tried all kinds of grid systems. We even went as far as placing a thousand pivots in the scene and snapping to those which was all kinds of lunacy. ? In the end it was just like everything else we have learned about coding. We start with three pages of non-sense which finally works once condensed to two lines of proper code. The best news, (for me), is that we finally know we can do what we want as far as game design. This kind of point/click 3/4 view system cuts my animation workload to almost nil. My crappy hand animations don't look too bad this way. In a 1st/3rd person type game I do not think they would make the cut. On top of that, the sheer number of animations for a game like that is just too much. For my abilities anyway. I have some GUI artwork to do, but I will post vids of it in action once that is done.

I have put the content on pause for a bit while I am deciding on grid sizes. In the interim we have worked on some other scripting ideas. It took two days, but we now have a basic point and click character control as well as basic AI... Content Update 5 We also added camera zoom and rotation into the mix. Neither of us are coders and are pretty much starting from zero so it is taking a while to get anything done. Although, slow progress is better than no progress I guess. We still have some major issues to tackle. Most important being a "grid" snap system for the reticule and therefore player movement. The pick collision is doing strange things, need to get that figured out as well. There seems to be a hard coded deceleration in the point to point motion that I just can not get rid of. Acceleration works as advertised, but the slow deceleration is always there. I am faking a quicker stop by stopping the character short of actually reaching the destination point at the moment. It looks a little better this way, but really it is just a hack fix.

Maybe I am approaching this the wrong way. I guess at the end of the day the actual scale, or unit of scale rather, does not really matter to me. A unit of measure is completely arbitrary in the real world. Relative might be a better word. I guess for the digital world a power of 2 is a constant. Maybe the thing to do here is use power of 2 dimensions eg: 128x128 grid and just treat my content as a 128 = meter. I can do that on export and it will be completely transparent. Either way, I will figure something out. This entire thread is just myself thinking out loud anyway.

I certainly did not go out of my way to come up with that number. Not in the way that you are thinking anyway. The idea was to come up with a standard grid size for my content. As you can see, all of the content there has a grid like aesthetic. There is a reason for that. Originally this grid was built around a meter. One grid = one meter. That obviously caused issues with the editor power of 2 grid once I started importing content over. So the compromise I came up with was 96cm which was fairly close to a meter and worked with the grid snap in the editor. This does in fact work except for the power of 2 to 96x96 UV tile scale issue. And in all honesty, that does not bother me as it is an easy work around. I do see other issues that might creep in later with the grid coordinates though. Objects centered on a game grid will not center on an editor grid. This would not matter for the little real time adventure type thing I have going on right now, but it might for a more turn based “tactical” design. I don’t know. I don’t know enough about the programming end of it to say, but it looks like that could be an issue from a common sense stand point. The issue with going full blown power of 2 for the grid size is 64 is too small and 128 is too large for a game grid in my opinion. From a strictly aesthetic standpoint anyway. That said, I may have to make another compromise here as well. In fact, as I have been typing this I have decided to try an make a 64cm game grid work.

It is just the scale that I happened to settle on is not optimal for use with the engine. If I use any power of 2 square on a 192cm square CSG, the UV scale = 0.75 and it lines up perfectly. If you cut that 192cm into quads and apply a power of 2 square texture, the scale needs to be 0.1875 to line up properly. The only issue with that is the engine rounds to the nearest thousandth. Either 0.187 or 0.188. It is a very subtle error, but after 4 tiles that little scale error adds up and you can see things not aligning properly. It’s not a big deal. This is the very reason I am testing like this. Another very quick fix that just came to mind is to stitch 4 1x1 tiles into a 4x4 texture.

Thanks gents! I did finally dial in the model scale. It took me a while to figure out that the Leadwerks importer was actually expecting centimeters and automatically converting to meters. Once I figured that out I was good to go. The scale issue I am having applies to the UV scale of textures applied to CSG's in the editor. One texture tile = 96cm in order for my content to line up properly. The 4x4 tiles match perfectly at 0.75. The 1x1 tiles equals out to 0.1875, but the editor rounds to the nearest thousandth. Again, staying under 4 tiles the scale error is pretty much a non issue. I also can easily fix this by just using meshes for single tile objects rather than CSG's.

Thanks carlb Here is a quick vid of everything in action... ContentUpdate4 Youtube really compresses the snot out of it, it looks a lot cleaner in person so to speak. Everything now snaps together super easy. I have a slight scale issue with the smaller texture tiles though. For a single "square" the scale needs to be 0.1875, but the closest I can get is 0.187-8. It works up to 4 tiles, but beyond that the scaling error is noticeable. Consequently the single tile floor adjacent to the floor grates are in 1x4 sections rather than a continuous run. I might just say the heck with it and just use meshes for the smaller bits. The larger 4x4 tiles are perfect though. These test props are super simple, but I am really seeing some potential here. I really want to do a TPS/RPG, but realistically I do not see that happening while I have a day job. This simple 3/4 content is doable though. ?

I had a major setback.? I remember reading in the documentation that the standard unit in Leadwerks was a meter which is what I built all of my content around. The idea is to be able to put most of the pieces in place using grid snap. I was not even paying attention to the grid sizes in the editor, I assumed that could be changed to whatever anyway. After hours of fighting the grid snap and placing objects by hand I decided I had to rebuild this content around the grid sizes. Lucky for me I noticed this early enough that most of this has been texture work so far. I have all of my objects resized and am back on track. I am now working on detail models.

I ran a few tests myself and there is a definite impact on frame rate when a lot of lights are involved. It was odd though, the impact seemed to be non-linear. 1-10 really had no impact at all. 10-30 had a steady impact. 50+ tanked the frame rate in a hurry. I don't know how hardware dependent this is either. The most important thing I learned is that you can have 10,000 lights on your map with no impact as long as they are not all being drawn at the same time. I will try to keep the light's on screen count under 10. I will also have to make sure the "detail" lights can be turned of on low spec machines.

No need to apologize. I was way off on what you were doing. I have my 3/4 view camera pretty much doing what you are trying to do. I can not say if it is in fact the right way to do it, but it works. You are welcome to take a look below. Script.rotation = 0 function Script:Start() end function Script:UpdateWorld() if window:KeyHit(Key.Q) then self.rotation = self.rotation +45 end if window:KeyHit(Key.E) then self.rotation = self.rotation -45 end end

My bad, I misunderstood what you were trying to do. I guess I just glossed over it and saw the error. Should that be?... function Script:Start() self.rotateC = 0 end function CameraRotate() self.entity:SetRotation(0,rotateC+90,0) End function Script:UpdateWorld() End

This thing is a monster! I am benchmarking with the new DOOM running Vulkan with ultra settings and averaging 175fps. (low has been 150 and it is capping at 200fps for some reason) For being desktop hardware it stays pretty cool as well. CPU was @75* and GPU was @60* during my DOOM session. ...but most important is Leadwerks works! Anyway, I am happy now and just thought I would share. And if anyone is looking for a laptop without a switchable GPU, the Acer Predator Helios 500 w/AMD Ryzen7/Vega56 is the ticket.

I don't know much about the scripting language myself, but try "== 0" rather than "= 0". I had an issue like that, the == through me for a loop as well. These are the important ones to remember: <=, >=, ~=, ==

Aye, you can attach objects to any bones in the hierarchy via the editor. I have done it with both mesh objects and lights. And while I can not speak for Blender, in Cheetah I can put separate meshes in the hierarchy and they are not actually assigned bone weights. The mesh as a whole is just driven by the bone. My test model’s hair, mask and goggles are attached this way. What I was suggesting is making the character out of individual pieces and having each piece be driven by the bones without any bone weight/skinning calculations. I am curious about this now myself. When I get home I will try and see how many of my test characters I can spawn before I see a serious performance hit.

If you can instance static geometry with the same kind of mesh complexity without this issue it would have to be the skinning performance. Leadwerks supports hardware skinning, and while that GPU is not great, it not THAT bad. One other test you could try, although tedious, would be to attach static meshes to each bone rather than using a skinned mesh. Preferably with objects that match the same poly count as the skinned mesh. That would isolate the skinned mesh performance from physics. Also, the hand animation to head bob de-sync might be caused by world update and physics update calls? Are both functions under the same update?

I think I am going to run a few test maps with 10's to 100's of lights without shadows and see what the impact is on some low spec hardware. Some very simple maps, just a cube maybe? Something to really isolate the lights impact. I have access to a few windows machines with integrated graphics at work.

Is there much of a performance hit when using a high number of lights if they do not cast shadows? I have done tests with a ton of lights without issue myself, but I have pretty stout hardware. Lets say I make a catwalk and I have lights running along both sides. I was wondering how much of an impact on low spec hardware it would be if I gave each light a small point light. No shadows of course. Is there a soft limit I should not go over per map?

I have weird issues with the probes and low light. Everything looks like it is made of bronze. Even the character model with no specular maps.

Thanks bud. Aye, it does need some "texture" work, that's for sure. It's the little things that really make it pop. Got a little more done today. I re-did everything I did yesterday, but kept everything cleaner. The bumps have been toned down considerably, maybe too much? I also added a few more variations. I had to throw some geometry in there just to fill space, but those boxes are nothing I plan to use. Hand rail is thinner. I will work on textures for the next few days, then start adding details. Lights, electronics, pipes, wires, etc.