Michael_J
-
Posts
202 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by Michael_J
-
-
An update on this: it is definitely a bug with the latest beta update. I've confirmed it does not happen with the previous beta data.
I understand this is beta and such. Just letting you know there is something going on...
-
Hi Josh,
You closed the other thread where I mentioned this is. While the other issues were resolved (thank you), I still get random cases of the mouse pointer not hiding when it should. This was not an issue before the recent beta updates that included the GUI work you added.
It SEEMS like a Windows wait icon (the small spinning circle thing) will trigger it. That's the only connection I've been able to make, but I can't say for certain that's the cause.
-
Just a head's up to AMD users about PlayTV (I believe that's how it's deployed--through AMD driver updates?)
PlayTV, beginning last night (an update I guess) suddenly caused ANY Leadwerks-based program (this included the Leadwerks Editor AND my game--Rogue System) to crash at random times during startup.
If you suddenly start encountering a Leadwerks crash at startup, check if you have PlaysTV installed. If you do, remove it and all will be well. The telltale sign of this is the error details:
Application Name: PFPX.exe
Fault Module Name: ltc_game32-114279.dll
So, Josh, THIS is what was causing the crash I was telling you about yesterday. Leadwerks Beta is fine...
-
1
-
-
OH, sorry--thought you meant "we" (as in the end-user) needed to rebuild. I saw the update this morning and thought everything on your end was good. My bad
-
Hmmm. Window::Center still missing after update, Clean and Rebuild. Not sure if it's needed or not, but I can't update my project through the Editor as it now CTD's at load...
Edit: And, RogSys crashes during load when building against this, too... The debugger doesn't even catch it when it does. Just FYI...
-
Since getting the most recent from the beta branch:
1) Getting a cannot open include file error for glslang/standalone/resourelimits.h even though glslang is in my include directories. In my Steam Leadwerks, there is no glslang\StandAlone folder. ResourceLimits.h is in glslang\Include
After adding the above directory and copying resourcelimits.h to it, I can build.
2)After being able to build again with the above change, I get a build error for:
'Center' : is not a member of 'Leadwerks::Window'.
You certainly didn't remove the ability to set the window to the center of the display, did you?
3) Also, since this update, seems like every so often the mouse cursor will not hide when it should. I haven't had a problem with this prior; and I haven't touched any code that would affect this on my end.
-
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);
-
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...
-
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...
Random mouse hide problem after lastest beta update...
in Leadwerks Engine Bug Reports
Posted
No suggestion on how to duplicate other than that I use the HideMouse() command to hide the mouse, and it doesn't. This gets called more than once, by the way, depending on the game's current state. This behavior does not occur in Leadwerks release version, and does on latest beta version.
The wait icon is arbitrary--it's visible because the mouse isn't hidden; but it's not a trigger as I first thought.
I build against the beta and it's broke. I build against the latest release and it's fine.