Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 27 Jan 2014
Offline Last Active Apr 28 2016 04:30 AM

Posts I've Made

In Topic: Downsampling texture size importance

17 April 2016 - 08:45 AM

Ah yes, I didn't think of using the viewport for this; that's useful!

The edge sampling is hopefully not an issue assuming my target images will be some power of 2 both before and after the "scaling", or am I wrong? (It will of course be upsampled back to the original resolution again before being used in any other process).

In Topic: Vertex buffer resource locking

16 April 2016 - 06:39 PM

The documentation says it will return that error code if it couldn't obtain the lock immediately, ergo you don't have the lock and as such shouldn't have to unlock it.

Whether trying to unlock it when you don't have the lock is an invalid operation or not I do not know however. The safest bet is of course to not try to unlock it in this situation.

In Topic: Problems with arcball rotation when dragging outside the "ball"

11 April 2016 - 04:38 PM

Thanks, that's a clear improvement!

Still not perfect though, and there's a somewhat significant jump once the cursor goes outside the sphere bounds. May another approach be more suitable?

In Topic: Static library adding exports to executable?

09 April 2016 - 02:35 AM

You you have a program that is using the assimp library, the open-source asset importing tool.
When you compile the final binary that links to a static build of assimp, the assimp library has functions available as exported functions which other programs can reach.
The program works fine, you have no compiler errors, the only concern is that some functions are visible externally?

Indeed, though the main problem lies in that they get jumbled into my intended exports for the dll build of my engine.

I only brought up them being in the executable version as well since that was additionally unexpected to me, ie. it shouldn't be my dll build settings that just "export everything imported" or similar.

Anyway, if it were just in the executable I probably wouldn't care about it but as it ends up in the dll builds, which are used by other people who have to sift through all these exports looking for my decorated functions in there (I can't just provide a header file for this since they're used through a language that doesn't support that), it is quite undesirable.




Libraries usually have a pair of macros, e.g. MYLIB_STATIC or MYLIB_SHARED and a MYLIB_EXPORT. If you have the wrong combination of these macros defined while building a library, you can get an assortment of linker errors or - as in your case - unintended exports.

Hm, I see, thanks.

The thing however is that the library in question doesn't have any explicitly declared macros or otherwise preceeding the function calls and they still end up exported, thus I was thinking that there may be some global linker flag to just "export everything".





... you'll possibly need to go through ../include/assimp/defs.h and change the calling conventions used through the system.


Thank you, I found ASSIMP_BUILD_DLL_EXPORT being unconditionally defined in there, hopefully undef:ing it should solve the issue!  :)

Edit: aye, that solved it. Thanks again!

In Topic: Interpolating between directional shadow maps to reduce edge shimmer

24 February 2016 - 04:44 AM

Sorry for the late reply.


I don't think you need to stabilize your shadowmap, heck Skyrim has been loved and played by so many people, and their sun shadowmapping looks horrible when updating - but people are just enjoying bashing dragons etc.

Haha, yes I was leaning towards that option as well, at least for the time being; I can always come back to try to improve the visuals later now that I at least have a working baseline system in place (and I'd rather move on to other parts for a while after being stuck with the lighting for longer than I'd care to admit). On the other hand I'm probably a bit too much of a perfectionist and just want to finish this with appealing results while I'm at it...


Or maybe you could try some alternative filtering methods instead?
I've implemented VSM shadows yesterday in my project, and the step from PCF shadowmapping to VSM gave me much smoother and nicer shadows (without bias artifacts)

That is an interesting approach. It does seem a bit cumbersome though as it seemingly requires two data channels (depth and squared depth) and thus has to be rendered to a colour render target (my current system relies a lot on depth-only passes since most of my geometry will be opaque and as such can have their depth maps rendered without the need for a pixel shader). Would you say that the improvements are great enough to warrant a change to such a system?



@JoeJ: Hm, interesting... I will see if I can dust off my linear algebra books and make sense of your calculations once my fever wears off tongue.png