Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Evgeniy Andreev
    @gsomix
    yeah, we need to update it everywhere
    Harald Steinlechner
    @haraldsteinlechner
    @ThomasOrtner @hyazinthh please test. what tod do:
    @gsomix Aardvark.Base.Extensions.SystemDrawing is for example for loading image from a system.drawing bitmap (e.g https://github.com/aardvark-platform/aardvark.base/blob/master/src/Aardvark.Base.Extensions.SystemDrawing/PixImageBitmap.cs#L94) or for converting our vectors to System.Drawing datatypes etc. it could be factored out easily but everything seems to get more complicated with more repos/solutions/buildscripts etc. with the buildscript fix we could stick with netcore/net47 mixed solutions right?
    Evgeniy Andreev
    @gsomix
    @haraldsteinlechner aren't bits of System.Drawing x-plat now?
    something like that
    https://www.fuget.org/packages/System.Drawing.Common
    Evgeniy Andreev
    @gsomix
    and primitives
    https://www.fuget.org/packages/System.Drawing.Primitives
    err, the last one looks strange :)
    Harald Steinlechner
    @haraldsteinlechner
    looks like it
    what hapens if i have a net471 project and now reference our package (which references system.drawing.common) and internally uses a framework reference to system.drawing? are those then compatible?
    Georg Haaser
    @krauthaufen
    i think since netcore 2.2 or something there is rudimentary Support for system drawing stuff and it should be compatible with old system.drawing stuff
    Harald Steinlechner
    @haraldsteinlechner
    so we would need to go to netcore 2.2 in order to use it
    i just reworked most readme.md files
    e.g. https://github.com/aardvark-platform/aardvark.rendering
    Offtopic, via @janneloni http://worrydream.com/AlligatorEggs/ ziemlich cool lol
    Georg Haaser
    @krauthaufen
    okay a little research brought up that only very basic datatypes are netstandard actually, but there's a community package providing most of the functionality for windows/linux/etc.
    maybe just move the whole thing to some other repo?
    in the unglygluecodestuff repo
    😀
    same thing where WPF and WinForms binding could go...
    Georg Haaser
    @krauthaufen
    hey @luithefirst @haraldsteinlechner @Plukers I'm currently cleaning up aardvark.base tests a little and found some tests that fail for various reasons. In some of these cases I can't figure out whether or not these things should work.
    e.g. Dict.GetOrCreate inside Dict.GetOrCreate
    and mostly super-weird incremental tests with concurrency (should we even have them?) can't be tested properly anyway
    Harald Steinlechner
    @haraldsteinlechner
    lui told mit about the getorcreate once
    what is going on here? https://travis-ci.org/aardvark-platform/aardvark.media . somebody seen this problem? or is just because of old build scirpt etc?
    Georg Haaser
    @krauthaufen
    had that exact same message on appveyor linux
    but I sadly couldn't figure out why
    Georg Haaser
    @krauthaufen
    a little status update for Aardvark.Base tests:
    • I ported all test-projects to netcore (had to remove Bitmap-Tests)
    • set some failing/slow tests to ignore (we should review those eventually)
    • the only project not being netcore/netstandard is now Aardvark.Base.Extensions.SystemDrawing
    ah sorry and the CodeGenerator of course
    so @haraldsteinlechner should we keep it that way?
    Effectively the most important tests are still alive and the ones that are concerned with concurrency and other non-deterministic things are mostly deactivated.
    On the upside running all the tests now "only" takes 5 minutes
    Evgeniy Andreev
    @gsomix
    so guys where is ModelUpdateView project from docs now?
    there is big tutorial on Aardvark.Media in wiki, it would be also nice to have code :)
    Harald Steinlechner
    @haraldsteinlechner
    @ThomasOrtner
    @gsomix awesome!
    Evgeniy Andreev
    @gsomix
    good morning
    I'm playing with renderdoc and HelloWorld example today, and I found captured by renderdoc OpenGL frames contains only red channel
    Vulkan's ones are colored. do I miss something?
    Evgeniy Andreev
    @gsomix
    is it a bug in renderdoc or feature of OpenGL renderer?
    Evgeniy Andreev
    @gsomix
    it seems something wrong with capturing vertices color data
    Evgeniy Andreev
    @gsomix
    btw where is DefaultOverlays defined? I cannot find it in aardvark.rendering
    Georg Haaser
    @krauthaufen
    hey, DefaultOverlays were removed some time ago as far as i remember. All the stats were quite hard to maintain, but maybe we should reimplement it when we have the time
    Evgeniy Andreev
    @gsomix
    it's time to remove it from examples :)
    Georg Haaser
    @krauthaufen
    yep
    Evgeniy Andreev
    @gsomix
    @krauthaufen btw is show { ... } prefered way for showing scene?
    examples in docs use low-level API with manual creation of app, window, etc
    Harald Steinlechner
    @haraldsteinlechner
    yes but for beginners show might be alienating. hello world examples should be low level imo
    Evgeniy Andreev
    @gsomix
    I see
    at least we can document both ways
    Evgeniy Andreev
    @gsomix

    I've updated PR and wiki a bit, so for now it's ready to merge @haraldsteinlechner

    aardvark-platform/aardvark.docs#22

    Evgeniy Andreev
    @gsomix

    @krauthaufen @haraldsteinlechner

    about .NET Core template. I'd prefer to have two separate templates: plain rendering app and UI app
    with parametrized backed

    I've created little experimental template for UI, please take a look
    https://github.com/gsomix/aardvark.template.ui