andrewmac
-
Posts
295 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Articles
Docs
Gallery
Posts posted by andrewmac
-
-
I googled it to see if there was any material about this. I'm guessing it's the same as the Gamasutra article only in presentation form:
-
There are a few cases throughout the engine where slower safe methods are implemented, usually following the pattern of safe(). For that reason, and performance concerns, I'd lean towards safeDivide() as the best option.
-
I use GENiE for Torque 6, which is a fork of premake by the author of bgfx:
https://github.com/bkaradzic/genie
I have no complaints about it. Took me about a day to get everything situated and I haven't looked back or had any trouble since. Works great for windows and linux, I haven't tested it on mac yet though.
I personally despise cmake.
-
Neat. I've been pursuing the idea of software occlusion culling for a bit now. I started a library I call SoftOcclude, based on intels work, to accomplish exactly this. Repo Link: https://github.com/andr3wmac/SoftOcclude
In the library, occludees are software rasterized to create a depth buffer completely on the CPU side without stalling the GPU. Then occluders are bounding box rasterized and tested against the depth buffer on the CPU ( same method as his ). Really, the only difference is where you get the depth buffer to test against. It would be trivial to adapt the library to use a supplied depth buffer instead of rasterizing one itself.
If anyone is interested in pursing this on the T3D side, let me know, I can help. I'm working on the library for Torque 6 usage, but it's very universal. Eventually it will be SSE optimized and threaded, which should be able to produce even better numbers than what he's getting, even if you're using the previous frames depth buffer instead of rasterizing a new one.
-
The list you're seeing is listing, from the top, the functions that are called the most and/or taking the most time. The point of looking at the profile is to figure out whats taking so long so you can try to reduce that particular item.
Seeing IsOccludedByTerrain seems odd because you don't have any terrain. And String::String() is odd because why is the engine spending so much time allocating strings? It almost seems like you're creating new strings every frame for some reason. Is there anything you can think of that's occuring per-frame that creates a new string? It may also be coming from torquescript.
-
For those too lazy to download and open the file, here's the top items:
%%NSTime %% Time Invoke # Name
889301.429 1412807.143 2966895 GenericConstBufferLayout_set
556268.571 556508.571 1168668 AdvancedLightManager_GetLightingShaderConstants
523953.810 523953.810 1100303 String_String_constructor
496644.762 503736.190 1057846 ShapeBase_ProcessTick
493198.571 523505.714 1099362 GFXD3D9ShaderBufferLayout_setMatrix
428440.000 428440.000 899724 FeatureSet_hasFeature
374434.286 374434.286 786312 RenderBinManager_setupSGData
247898.571 249967.143 524931 LightManager_Update4LightConsts
224756.667 228688.571 480246 ProcessedShaderMaterial_SetShaderConstants
223342.381 223342.381 469019 ProcessedShaderMaterial_stepInstance
221014.286 228688.571 480246 ProcessedShaderMaterial_SetTextureTransforms
211990.952 211990.952 445181 VectorResize
184622.857 184622.857 387708 SceneCullingState_isOccludedByTerrain
134128.571 134128.571 281670 String_default_constructor
133589.524 133589.524 280538 GFXD3D9ShaderConstBuffer_activate_dirty_check_1
130927.619 236888.571 497466 GFXDevice_updateStates
107886.190 241475.714 507099 GFXD3D9ShaderConstBuffer_activate
106340.476 106340.476 223315 GFXD3D9VertexBuffer_unlock
105960.952 105960.952 222518 GFXD3D9StateBlock_Activate
103763.333 103763.333 217903 GFXD3D9Device_findVBPool
-
Did you run the debug build? Things don't usually just crash with no debug information. Is it producing an error?
-
Is it still failling in the same way? With a crash related to memory allocation?
I feel I have to ask this question: are the PC's that crash with the 64-bit version running 64-bit windows? If they're running 32 it's not going to work.
And finally I figured I should comment on this:
Because even with things working as well as they are now, theoretically if we add enough to the ship then a person could still hit a total memory ceiling eventually if they only have 4 gigs of ram.The 32/64 bit limitation is in memory addresses. In 32-bit you can't address more than 2 GB worth of spots and then you run out of addresses. Once you move to 64-bit you've got plenty of addresses to work with. Running out of RAM is a different issue though. When you start to run out of RAM, your computer will swap lesser used data in RAM onto the harddrive to make space. This is called Virtual Memory. It prevents applications from crashing due to physical memory restrictions. So, someone running with 4 GB of RAM will not see a crash when you load more than 4 GB of assets into your game. It will make things slower, etc, but the application should not crash. The same would be true about running a 32-bit copy of your game on a machine with only 1 GB of RAM. It will overflow into virtual memory, but you'd still get your crash if you hit ~1.8 GB of usage, since you run out of memory addresses.
-
http://i.imgur.com/QAn71oT.jpg
Tapa tapa tapa!
-
Yeah, 1.7-1.8 GB of usage is about where things start to break down. Rising memory with no input is generally a memory leak. Memory is being allocated but not freed.
My approach was just to remove things from my level until I discovered where large amounts of usage were coming from. To be honest though, its 2015, 32-bit is on its deathbed, I think you'd be better off spending the time trying to get Awesominum working in 64-bit.
-
You can use as much total system memory as you have available (and then some with virtual memory) but for the actual T3D application itself, it can't exceed 2 GB of memory usage when built in 32-bit. When it starts getting close to the limit, memory allocations will start to fail and you'll get a random crash from the next place that trys to use some memory that failed to allocate.
It should be simple to check, just launch the game, run it for awhile, then open your task manager and check how much memory your game is using. If its anywhere near 2 GB, that's your problem. If it's no where near 2 GB, ignore everything I just said :D
-
If you're getting a consistent crash, then yeah, trace it down.
If you're getting random crashes like the one you were talking about above, open up the task manager and look at the amount of memory usage you're using. If it's up around 2 GB, you're near the limit and problems are going to start happening.
I used to start getting crashes from random spots when I was sitting around 1.85 GB of RAM usage.
-
Are you using 32-bit build or 64-bit? If you're using 32-bit you're probably running out of memory.
-
Agreed!!!
Daniels walkabout im sure took many hour to create and his nav mesh editor the same but now navmesh is apart of the main branch
Recently, sure, but Daniel used to sell walkabout. I paid for it, I'm sure many did. He deserved the money, it's good work.
I'm not asking for money for my work (not to imply that's a negative thing), or any kind of compensation. I just want my name to remain on it, is that really asking so much?
-
This isn't a resource and was never presented as such, I have no interest in porting it to deferred lighting. You're on your own, good luck.
-
As I mentioned I have it compiling but it crashes upon load any level..The breakpoint or crash points to \source\materials\matinstance.cpp(521,0): {Fatal} - Not init'ed!
and another points to shaders/common/lighting/advanced/vectorLightP.hlsl(263,11): error X3013: 'autogenCondition_bde4cbab': function does not take 6 parameters
Failed to initialize material 'AL_VectorLightMaterial'
Vector lights weren't changed for offlineLPV. You're porting changes from deferred shading into deferred lighting. You're going outside of the scope of the changes for OfflineLPV. Honestly dude, maybe you should just wait for Az or someone else to do it. You can't just blindly copy files from A to B and hope it works in this case. You have to analyze what's been changed and do a proper port (hence the term porting).
-
I haven't tried pushing this in T3D personally, but modern GPUs can handle up to 16384x16384 texture size. I don't see any imposed limits in the texture loading code, though I didn't dig that deep. I guess your best bet would be to try it and report back with any issues :D
-
Deferred lighting and shading (and even forward) are all per-pixel lighting techniques so I don't know why anyone is throwing around that term.
Offline LPV just renders into the lighting buffer that's used in both deferred lighting and shading, there's no reason Offline LPV wouldn't work in deferred lighting.
-
I'm pretty sure it already does this. I can't think of any examples where the gun doesn't render over things. The only difference is with T3D it pushes the weapon back as you get close to a wall. I haven't tested it, but I believe the only code doing this is this:
Be advised though, that removing that bit will let you shoot through a wall. Once you move the muzzle into the wall the muzzle starting point will be past the wall and your bullet will start after the wall. I think this can be avoided by just approaching the problem from here:
As far as I can tell removing that bit would prevent the rendered muzzle vector from being corrected for collision, but still leave the actual muzzle vector corrected. There is a chance drawing the weapon is depth tested ( I didn't look ), resulting in the weapon being clipped by the wall you're walking into, this can be avoid by turning off depth testing in the stateblock for the shape image.
-
Could you elaborate on this idea? I've never heard of a culling mask before, so I googled it and found this video from Unity:
Could you explain how this concept would be applied to the issue you're experiencing?
-
@J0linar : the URL just got truncated:
-
It's too low frequency to produce any kind of meaningful AO results :( All the LPV implementations I've seen supplement it with SSAO.
-
I've actually just recently added 4 new options for LPVs:
Light Intensity : multiplies the intensity of the lights injected into the grid
Emissive Intensity : same as light intensity only for emissive materials
Propagation Multiplier : multiplies the intensity of the light after each propagation step.
GI Multiplier : multiplies the intensity of the final result. This is useful if you like the spread but the overall result is too strong or too weak.
This allows a much greater degree of control over the final result. Also, while lighting rooms entirely with emissive I noticed a big missing piece. Ambient occlusion! We have SSAO, so I tossed it on. Unfortunately SSAO only applies to the sunlight, so I added support for it in the LPV shader:
http://i.imgur.com/9aqrY6c.png
All these changes have been pushed. I'm pretty much out of new things to add at this point. The only thing left to do is tweak the algorithms to see if we can reduce light bleed and improve propagation. It's my first time doing anything with spherical harmonics so I'm sure it could be better. My goal was to make an Offline Light Propagation Volume and it's getting close to complete. There's lots more than can be done (dynamic lights, voxel cone tracing, etc) but it starts going outside the scope of an offline light propagation volume. I've got to get back to working on other things though so I'm going to try to wrap this up in the next few days.
-
JeffR's voxelization is in and we've got it detecting proper UV coordinates from the verts and pulling the color from the textures. Also, emissive materials are now actually emissive! They're injected into the light grid and propagated like any other light source:
http://i.imgur.com/Ni3i5az.png
SMAA
in Rendering
Posted
I've seen a few implementations in Unity that claim to have it working in OpenGL, but I haven't seen anyone actually get the original posted smaa.hlsl file on github to work with OpenGL. Even after he modified it add GLSL support, I'm not entirely convinced it works.
I hit the exact same issue you did implementing it in Torque 6. I've also found 3 or 4 forum posts around the internet where people hit the same wall myself and you have hit; the blend weight pass just doesn't come out right in GLSL and the final pass falls apart because of it.