Michael_J

Getting a cannot open include file error for glslang/standalone/resourelimits.h after this update, even though glslang is in my include directories Edit: Yeah, in my Steam Leadwerks, there is no glslang\StandAlone folder. ResourceLimits.h is in glslang\Include

Edit: got it, yes. Thanks Josh....

Got it--thanks!

I don't really see where you expose the data needed to use Newton functions such as http://newtondynamics.com/wiki/index.php5?title=NewtonCollisionCollide Is there a way to at least get the NewtonBody pointer for a Leadwerks entity that has collision? This would then allow me to get the required information using other Newton functions such as http://newtondynamics.com/wiki/index.php5?title=NewtonBodyGetWorld Thanks

Ah, that makes sense... Ok, is there any type that acts like a trigger (no physics response), but does perform a "regular" collision test (understanding the limitation that if one object is inside another the test would fail); or could one be added in short order? Namely, I'd like to do some VFX work where a collision occurs between two objects, but I don't want a physics reaction when this happens. Depending on the shapes of the objects, a ray test wouldn't always work for something like this...

Can anyone else verify that a collision callback, when the response type is Trigger, only returns 0,0,0 for position and normal. Setting the response type to Collide returns expected results. I mean, even if the response is only a trigger, it should still be able to return at LEAST where the collision took place, yes?

Sure... Tiled diffuse on TexCoord 1 baked lighting on texCoord 2 High detail stains, insignia, etc THAT ACCEPT THE BAKED LIGHTING (decals would not) with TexCoord 3 Baked lighting is STILL often a viable solution, especially for AO.

what you're animating may very well need unique mapping regardless. But that was just an example. The point is, there are many artistic reasons to make use of 2 and even 3 unique sets of texcoords. I've been a professional 3D environment and FX artist since 1999--I'm not just making this stuff up However, this is your engine. If you only want to support 2 UV map channels that's fine (regardless if I agree or not). Just tell me so I can come up with an alternative...

It's pretty important if you're doing multi-layered and/or effects art AND want to save texture space. An example: TexCoord 1: tiled maps for the diffuse layer (higher texture detail without using large maps) TexCoord 2: a baked AO map, spec mask, or normal map that requires a one-to-one mapping TexCoord 3: UV animated effects, layered texture details, or other effects elements that require their own unique coordinates.

Well, that explains that. So.... is there any chance of supporting three? Artistically speaking, I would consider three UV map channels (or texcoord channels, if you prefer) the minimum once you start getting into more advanced art. If not, then you might as well close this thread and I'll try to come up with some work-around...

So, I'm trying to import an FBX object with 3 unique UV map channels. It appears that the importer is not handling the 3rd map channel though. The results I'm getting in the editor would suggest this at least. I imported the object back into MAX, into a new file, and the 3rd map channel is there; so I know that the MAX FBX exporter is storing the data correctly. Josh, can you confirm that the 3rd map channel is infact being "ignored" by the importer. If so, I would consider this a bug--there are many reasons why you'd want the ability to have three and even four unique map channels. Otherwise, then the bug is with my shader. In theory, this should work, yes? Vertex shader: in vec2 vertex_texcoords2; out vec2 ex_texcoords2; ex_texcoords2 = vertex_texcoords2; Fragment shader: in vec2 ex_texcoords2; vec4 paint = texture(texture5,ex_texcoords2); SV46_hull_TAILlogo.FBX

Sorry--didn't specify. That would be camera multi-sample...

I've had a few Rogue System customers report this in the past couple of weeks (not many, but a few). In these cases, setting AntiAliasing to a value of 2 or more (up to whatever your card supports) corrects the issue...

For what it's worth, I have people running Rogue System on Win10 machines with, seemingly, no problems

Update: using camera->debugphysicsmode it APPEARS (and it's kind of hard to tell as I immediately start falling away from the ship) as though the collision doesn't exist.. Also, now that I look closer in the editor, it seems like the "collision" limbs are being imported and displayed as "art" geometry, rather than collision geometry, if that makes sense. Take a look at the FBX in the editor and you should be able to see what I mean... Thanks!

Sure Josh, here's a piece of a ship interior with simplified collision defined (yes, by exporting "collision" objects along with the art object from MAX). Here's the FBX, too, if needed... S31c_INThull01.mdl S31c_INThull01.FBX

The update from either 6/23 or 6/24 now causes the character controller to fall through collision that was previously working. As a test, I "reverted" to the April archive and the character controller again started working fine, so this is definitely a recent change in Leadwerks that has caused this. Josh, I sent you a PM on this with a few more details about what sort of collision has been affected, etc. And, just in passing, there seems to have been a definite performance increase between the April archive, and an update sometime during early May. I'd be perfectly fine falling back to a May archive, but unless I missed it I don't think one is present as an option on Steam. Thanks...

Damn, you know, I could SWEAR I tried this before and I still got a border... :S Okay--that works a treat. This can be closed--sorry for the brain-fart...

I know of the methods to add title bars and what not, but I don't BELIEVE there is a way to create a border-less window. I have many users that like to use windowed mode, and prefer to not have the border (and I've seen this done in many games for this reason). Thanks...

Unless I missed a method that already does this... It would be great to have something to tell how many monitors are in use, the current resolution of each, and which monitor to open the window on. I know this info can be found using various windows methods, but something native (so the support is available for Windows, Linux, with C++ and LUA) would be appreciated, I think... Thanks...

I tried just adding the .dll's--didn't work for me. I just included the installed in a "Utilities" folder if needed (which obviously doesn't help in your case). Yeah, was just planning on having the installer do it once I have one set up...

Got ya--thanks for that.

Ah, okay. Thought maybe you might want this on the engine side. I'll give this a go--thanks

This isn't exactly a bug, so I thought it be better to post here. I was wondering if there was a more graceful way to handle when someone tries to run a Le-based program using a card that does not support OpenGL 4.0. Right now, at least for RogSys' testers, they simply get a crash. Is it possible to put up a message similar to what you do when OpenAL can't be found? Just curious--thanks

Out of curiosity (and something you didn't specifically mention, which is why I ask), do you have any plans for general (or specific) optimizations? Any places you can readily see where the rendering pipeline might be made more efficient? I think I recall you mentioning something about FBO's, but can't remember specifically... Nice work on the new tutorials and such--anything to help people ease into Le quicker can't be a bad thing