Assimp, stbi and tinydds integation integration with vsgXchange

[Robert Osfield]

Hi All,

I'm delighted to announce that André Norman's work on leveraging Assimp, stdbi and tinydds to add support for a wide range of 3d model and image formats is now checked into vsgXchange master (I've even been inspired to add some info to the vsgXchange README.md explaining project dependencies, usage etc.) :

     https://github.com/vsg-dev/vsgXchange

Changes associated with these additions:

    https://github.com/vsg-dev/vsgXchange/pull/25

With André help I've been refining both the new additions and refactoring the core VSG to add support for cubemaps and texture 2D arrays.  This means you'll need to updated to VSG master to build the new changes.  The changes to core VSG are:

    https://github.com/vsg-dev/VulkanSceneGraph/pull/255

The bit of glue that helps the cubemap and texture 2D array side get setup automatically is the setting of a new vsg::Data::Laout member imageViewType that is set by the image readers to specify whether it's 1D, 2D, 3D, Cubemap, 1D Array, 2D Array or Cubemap Array. 

This new vsg::Data::Layout property is serialized to/from the native VSG format, and tto enable backwards compatibility I've bumped the VSG version to 0.0.4.

As as image and 3d model loading André adds PBR shaders so that models that contain the required data such as GLTF models can render with PBR out of the box, no additions to your application are required - just load the data!

Below a few models from the GLTF example set to illustrate this all in action - I either used vsgviewer or vsgskypbox to load these models.

Many thanks to André for his efforts on this valuable new functionality.

Cheers,

Robert.

[Chris Hanson]

Looks sweet. Great work guys!

--
You received this message because you are subscribed to the Google Groups "vsg-users : VulkanSceneGraph Developer Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vsg-users+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vsg-users/ab8188fc-6ad2-40b3-a742-27931fc89025n%40googlegroups.com.

--

Chris 'Xenon' Hanson, omo sanza lettere. Xe...@AlphaPixel.com http://www.alphapixel.com/

Training • Consulting • Contracting

3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL

Legal/IP • Forensics • Imaging • UAVs • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile • iPhone/iPad/iOS • Android

@alphapixel facebook.com/alphapixel (775) 623-PIXL [7495]

[Trajce Nikolov NICK]

Hi Robert,

here is what I am getting on Windows 

1>------ Build started: Project: ZERO_CHECK, Configuration: Release x64 ------

1>Checking Build System

1>CMake is re-running because C:/Dev/vsgExamples/CMakeFiles/generate.stamp is out-of-date.

1>  the file 'C:/Dev/vsgImGui/lib/cmake/vsgImGui/vsgImGuiTargets-release.cmake'

1>  is newer than 'C:/Dev/vsgExamples/CMakeFiles/generate.stamp.depend'

1>  result='-1'

1>-- Selecting Windows SDK version 10.0.18362.0 to target Windows 10.0.18363.

1>-- Found glslang: C:/VulkanSDK/1.2.154.1/Lib/glslang.lib

1>-- Found glslang: C:/VulkanSDK/1.2.154.1/Lib/glslang.lib

1>-- Found glslang: C:/VulkanSDK/1.2.154.1/Lib/glslang.lib

1>-- Configuring done

1>CMake Error at examples/viewer/vsgskybox/CMakeLists.txt:13 (add_custom_command):

1>  Error evaluating generator expression:

1>

1>    $<TARGET_FILE:KTX::ktx>

1>

1>  No target "KTX::ktx"

1>

1>

1>CMake Error at examples/viewer/vsgskybox/CMakeLists.txt:13 (add_custom_command):

1>  Error evaluating generator expression:

1>

1>    $<TARGET_FILE:KTX::ktx>

1>

1>  No target "KTX::ktx"

1>

1>

1>CMake Error at examples/viewer/vsgskybox/CMakeLists.txt:13 (add_custom_command):

1>  Error evaluating generator expression:

1>

1>    $<TARGET_FILE:KTX::ktx>

1>

1>  No target "KTX::ktx"

1>

1>

1>CMake Error at examples/viewer/vsgskybox/CMakeLists.txt:13 (add_custom_command):

1>  Error evaluating generator expression:

1>

1>    $<TARGET_FILE:KTX::ktx>

1>

1>  No target "KTX::ktx"

1>

1>

1>CMake Error at examples/viewer/vsgskybox/CMakeLists.txt:13 (add_custom_command):

1>  Error evaluating generator expression:

1>

1>    $<TARGET_FILE:KTX::ktx>

1>

1>  No target "KTX::ktx"

1>

1>

1>CMake Error at examples/viewer/vsgskybox/CMakeLists.txt:13 (add_custom_command):

1>  Error evaluating generator expression:

1>

1>    $<TARGET_FILE:KTX::ktx>

1>

1>  No target "KTX::ktx"

1>

1>

1>CMake Error at examples/viewer/vsgskybox/CMakeLists.txt:13 (add_custom_command):

1>  Error evaluating generator expression:

1>

1>    $<TARGET_FILE:KTX::ktx>

1>

1>  No target "KTX::ktx"

1>

1>

1>CMake Error at examples/viewer/vsgskybox/CMakeLists.txt:13 (add_custom_command):

1>  Error evaluating generator expression:

1>

1>    $<TARGET_FILE:KTX::ktx>

1>

1>  No target "KTX::ktx"

1>

1>

1>-- Generating done

1>CMake Generate step failed.  Build files cannot be regenerated correctly.

1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(234,5): error MSB6006: "cmd.exe" exited with code 1.

1>Done building project "ZERO_CHECK.vcxproj" -- FAILED.

2>------ Build started: Project: vsgimgui, Configuration: Release x64 ------

3>------ Build started: Project: vsgskybox, Configuration: Release x64 ------

3>vsgskybox.vcxproj -> C:\Dev\vsgExamples\bin\Release\vsgskybox.exe

2>vsgimgui.cpp

3>EXEC : CMake error : cmake version 3.17.2

3>Usage: C:\Program Files\CMake\bin\cmake.exe -E <command> [arguments...]

3>Available commands:

3>  capabilities              - Report capabilities built into cmake in JSON format

3>  chdir dir cmd [args...]   - run command in a given directory

3>  compare_files [--ignore-eol] file1 file2

3>                              - check if file1 is same as file2

3>  copy <file>... destination  - copy files to destination (either file or directory)

3>  copy_directory <dir>... destination   - copy content of <dir>... directories to 'destination' directory

3>  copy_if_different <file>... destination  - copy files if it has changed

3>  echo [<string>...]        - displays arguments as text

3>  echo_append [<string>...] - displays arguments as text but no new line

3>  env [--unset=NAME]... [NAME=VALUE]... COMMAND [ARG]...

3>                            - run command in a modified environment

3>  environment               - display the current environment

3>  make_directory <dir>...   - create parent and <dir> directories

3>  md5sum <file>...          - create MD5 checksum of files

3>  sha1sum <file>...         - create SHA1 checksum of files

3>  sha224sum <file>...       - create SHA224 checksum of files

3>  sha256sum <file>...       - create SHA256 checksum of files

3>  sha384sum <file>...       - create SHA384 checksum of files

3>  sha512sum <file>...       - create SHA512 checksum of files

3>  remove [-f] <file>...     - remove the file(s), use -f to force it (deprecated: use rm instead)

3>  remove_directory <dir>... - remove directories and their contents (deprecated: use rm instead)

3>  rename oldname newname    - rename a file or directory (on one volume)

3>  rm [-rRf] <file/dir>...    - remove files or directories, use -f to force it, r or R to remove directories and their contents recursively

3>  server                    - start cmake in server mode

3>  sleep <number>...         - sleep for given number of seconds

3>  tar [cxt][vf][zjJ] file.tar [file/dir1 file/dir2 ...]

3>                            - create or extract a tar or zip archive

3>  time command [args...]    - run command and display elapsed time

3>  touch <file>...           - touch a <file>.

3>  touch_nocreate <file>...  - touch a <file> but do not create it.

3>  create_symlink old new    - create a symbolic link new -> old

3>  true                      - do nothing with an exit code of 0

3>  false                     - do nothing with an exit code of 1

3>Available on Windows only:

3>  delete_regv key           - delete registry value

3>  env_vs8_wince sdkname     - displays a batch file which sets the environment for the provided Windows CE SDK installed in VS2005

3>  env_vs9_wince sdkname     - displays a batch file which sets the environment for the provided Windows CE SDK installed in VS2008

3>  write_regv key value      - write registry value

3>

3>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(149,5): error MSB3073: The command "setlocal

3>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(149,5): error MSB3073: "C:\Program Files\CMake\bin\cmake.exe" -E copy_if_different C:/Dev/VSG/lib/vsg.lib C:/Dev/vsgExamples/bin/Release

3>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(149,5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd

3>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(149,5): error MSB3073: "C:\Program Files\CMake\bin\cmake.exe" -E copy_if_different C:/Dev/vsgXchange/lib/vsgXchange.lib C:/Dev/vsgExamples/bin/Release

3>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(149,5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd

3>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(149,5): error MSB3073: "C:\Program Files\CMake\bin\cmake.exe" -E copy_if_different  C:/Dev/vsgExamples/bin/Release

3>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(149,5): error MSB3073: if %errorlevel% neq 0 goto :cmEnd

3>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(149,5): error MSB3073: :cmEnd

3>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(149,5): error MSB3073: endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone

3>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(149,5): error MSB3073: :cmErrorLevel

3>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(149,5): error MSB3073: exit /b %1

3>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(149,5): error MSB3073: :cmDone

3>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(149,5): error MSB3073: if %errorlevel% neq 0 goto :VCEnd

3>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(149,5): error MSB3073: :VCEnd" exited with code 1.

3>Done building project "vsgskybox.vcxproj" -- FAILED.

2>vsgimgui.vcxproj -> C:\Dev\vsgExamples\bin\Release\vsgimgui.exe

4>------ Build started: Project: ALL_BUILD, Configuration: Release x64 ------

========== Build: 2 succeeded, 2 failed, 31 up-to-date, 0 skipped ==========

To view this discussion on the web, visit https://groups.google.com/d/msgid/vsg-users/CAGoufmbZqKr6WM0F288mn3vvcOK04S8_1ErXNRTja2mpohbfXQ%40mail.gmail.com.

--

trajce nikolov nick

[Robert Osfield]

HI Nick,

On Thu, 11 Feb 2021 at 07:45, Trajce Nikolov NICK <trajce.ni...@gmail.com> wrote:

1>CMake Error at examples/viewer/vsgskybox/CMakeLists.txt:13 (add_custom_command):

1>  Error evaluating generator expression:

1>

1>    $<TARGET_FILE:KTX::ktx>

1>

1>  No target "KTX::ktx"

I didn't spot the KTX references when I checked in vsgskybox.  I've now removed these:

    https://github.com/vsg-dev/vsgExamples/commit/bc45628a5a95474ea77cf9fd750137438b87549a

I presume Andre needed to add these KTX references for his original vsgXchange integration KTX.  KTX support in vsgXchange isn't merged yet, even once it is we should be able to avoid pushing specific dependencies into the local CMakeList.txt files.

 Could you update vsgExamples and let me know how you get on.

Cheers,

Robert.

[Trajce Nikolov NICK]

Hi Robert,

all good now! Thanks a bunch!

Cheers,

Nick

--

You received this message because you are subscribed to the Google Groups "vsg-users : VulkanSceneGraph Developer Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vsg-users+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vsg-users/CAFN7Y%2BW5tP5vxN88wf_PyhqFZQidEaOoMWi3sdFxdmODcizJQA%40mail.gmail.com.

--

trajce nikolov nick

[Andre Normann]

Yes, this was my initial checkin. But it is not needed anymore.

Cheers,

André

--

You received this message because you are subscribed to the Google Groups "vsg-users : VulkanSceneGraph Developer Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vsg-users+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vsg-users/CAFN7Y%2BW5tP5vxN88wf_PyhqFZQidEaOoMWi3sdFxdmODcizJQA%40mail.gmail.com.

[Robert Osfield]

On Thu, 11 Feb 2021 at 08:43, Andre Normann <andre....@gmail.com> wrote:

Yes, this was my initial checkin. But it is not needed anymore.

Thanks for the clarification. 

I'm now working on the KTX support and have checked in updates to the vsgXchange KTX_useArray3D branch to work with the new vsg::Data::Layout.imageViewType.  I'll leave the original KTX branch as is, though it won't work with VSG master.  I will next look at how easily I can build a readKTX library rather than have the KTX source in vsgXchange.

[Robert Osfield]

Hi All,

I have just tracked down a bug in vsg::ComputeBounds that was causing models containing nested vsg::MatrixTransform to compute incorrect bounds.  A fix for this is in VulkanSceneGraph master.

This bug lead to models loading and the new default camera position being put in the wrong place, so some models were incorrectly sized or positioned, or not even visible at all. With this fix models loaded in vsgviewer are centered correctly in the window.   This means that when testing assimp with a wide range of models they now all load up correctly and look great :-)

Cheers,

Robert.

[Andre Normann]

Hi Robert,

I do not see this fix. Have you synced it with the github repo?

Cheers,

André

--
You received this message because you are subscribed to the Google Groups "vsg-users : VulkanSceneGraph Developer Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vsg-users+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vsg-users/CAFN7Y%2BVtwKccU2DRW7ZVZi-6DLd-PsWz3BjGMH0RNZ8%2BVEvJcA%40mail.gmail.com.

[Robert Osfield]

On Sun, 14 Feb 2021 at 15:59, Andre Normann <andre....@gmail.com> wrote:

I do not see this fix. Have you synced it with the github repo?

Sorry about that, looks like I did a push then heading away from the machine and didn't spot the error.

I've pushed again, with another unrelated fix :-)

 

[Robert Osfield]

I ma currently writing a new VSG example to illustrate how to manage dynamic loading of data.  I have yet to write the dynamic loading part, but along the way towards this I've done a test of loading all the models on the command line and placing them into a regular grid, scaling each object to a unit radius of 1.0.  This is what you see if you attempt to load all the glTF-Sample-Models together at one time.  It almost (92%) fills my 6GB NVidia Geforce 2060 card but still runs at 60hz!

[Robert Osfield]

[Gavin McIntosh]

Hi Robert,

It would be interesting to try this on Intel 940/5 GPU's. 

Those are supposed to be Tile engine based, also used for simulating Raspberry Pi GPU's.

Vulkan is supposed to be good on Tile engine GPUs like those used in Mobilephone SoCs.

Late last night finally realized I was not testing the assimp branch.

On the Pi, cmake is not finding assimp.

Downloaded, compiled and installed the latest assimp version.

Could be a path or alias issue?

Been converting stuff from osg.

The osg Dumptruck did not convert to vsgt properly, weird vertex issues?

The others without particles seem fine.

Cessnafire.osg was plain, vsg has no particles yet?

Regards

Gavin

[Robert Osfield]

Hi Gavin,

On Mon, 15 Feb 2021 at 01:31, Gavin McIntosh <g.mci...@griffith.edu.au> wrote:

It would be interesting to try this on Intel 940/5 GPU's. 

Those are supposed to be Tile engine based, also used for simulating Raspberry Pi GPU's.

Vulkan is supposed to be good on Tile engine GPUs like those used in Mobilephone SoCs.

So you have such a system to work with?  My main dev system in AMD + NVidia right now.

  

Late last night finally realized I was not testing the assimp branch.

On the Pi, cmake is not finding assimp.

Downloaded, compiled and installed the latest assimp version.

Could be a path or alias issue?

What version of Assimp did you previously have installed?

 

Been converting stuff from osg.

The osg Dumptruck did not convert to vsgt properly, weird vertex issues?

I have dumptruck.osgt loading fine.  What issue do you see?

 

The others without particles seem fine.

Cessnafire.osg was plain, vsg has no particles yet?

The VSG doesn't have any particle implementation to map osgParticle to so particles won't be mapped across.

The way to do particles in the VSG will be to use a combination of shaders, exactly what implementation you'd go for would depend upon the needs of the particle system effect desired.  I don't think it makes sense to attempt to replicate old CPU based libs like osgParticle, even on the GPU, and don't plan for the core VSG library itself ever providing particle systems.

If one was to build a game engine on top of the VSG then I'd expect such a project to tackle particle systems in a form that is appropriate for their needs. The other alternative is for a utility library like vsgImGui to be developed for particle systems.

Cheers,

Robert.

[Gavin McIntosh]

Hi Robert,

My kid refuses to give me my AMD/Nvidia game PC back,  so now Pi4's and a Pi400 are my home PC's.

Intel GPU might be in a laptop or old all in one motherboard, will need to check.

I really need a PC x86 Linux to compare the Pi against.

Pi OS had assimp 4.1 as default?

Had one error that indicated 5 will fix it, it seemed to.

Once that is working all those 3D models become usable, huge step forward.

Not too worried about Dumptruck yet, suspect those Vulkan drivers, maybe Normals?

Still need to get a working 32bit OS, first spin gave many errors.

I will look at the Vulkan particle stuff, shaders etc, lots of learning to do there.

Compute shaders are supposed to work in OpenGLES 3.1 on the Pi, how that translates to Vulkan I don't know yet.

I keep breaking Sascha Williams examples.

Still impressed with how good vsg is on a Pi already.

My new Pi400 is faster so compiling is quicker now.

No game engine has Vulkan yet on the Pi that I have tried.

VKQuake I think is working. Might have a look at that.

Panda3D and Godot are getting closer to working Vulkan versions.

But for Sim/GIS use vsg should be much easier to use.

Regard

Gavin

---

From: vsg-...@googlegroups.com <vsg-...@googlegroups.com> on behalf of Robert Osfield <robert....@gmail.com>
Sent: Monday, February 15, 2021 5:55 PM
To: vsg-...@googlegroups.com <vsg-...@googlegroups.com>
Subject: Re: [vsg-users] Assimp, stbi and tinydds integation integration with vsgXchange

 

--
You received this message because you are subscribed to the Google Groups "vsg-users : VulkanSceneGraph Developer Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vsg-users+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vsg-users/CAFN7Y%2BVj3USd1v5RUpbGoFT2u2itMQjiKQ1w6sPjC9G5Ne-v7w%40mail.gmail.com.

[Robert Osfield]

Hi Gavin,

On Mon, 15 Feb 2021 at 08:33, Gavin McIntosh <g.mci...@griffith.edu.au> wrote:

My kid refuses to give me my AMD/Nvidia game PC back,  so now Pi4's and a Pi400 are my home PC's.

Intel GPU might be in a laptop or old all in one motherboard, will need to check.

I really need a PC x86 Linux to compare the Pi against.

Having a desktop system to compare against would be useful as a sanity test.  I've long been an NVidia user simply because they had the best OpenGL drivers, but I believe with Vulkan the playing field is far more level w.r.t quality of drivers.  This should mean Intel and AMD cpus with integrated graphics should be able to run to the best of their abilities.

 

Not too worried about Dumptruck yet, suspect those Vulkan drivers, maybe Normals?

Is the Vulkna debug layer available?  This would give some feedback.

 

I will look at the Vulkan particle stuff, shaders etc, lots of learning to do there.

Compute shaders are supposed to work in OpenGLES 3.1 on the Pi, how that translates to Vulkan I don't know yet.

I keep breaking Sascha Williams examples.

This is where a stable desktop system would help - learn the required functionality on a quick and robust system where you know errors that occur are most likely down to the your own mistakes vs for ever wondering if it's a driver issue.

 

Still impressed with how good vsg is on a Pi already.

My new Pi400 is faster so compiling is quicker now.

Ooo, I didn't know about the Pi400, just looked. Does it all work off the shelf, or do you still have to install OS and setup?

[Robert Osfield]

I just realized that Andre's vsgskybox creates a scene graphs to render the skybox, as I the VSG has serialization I was able to write to out to disk via:

    vsgskybox --skybox textures/skybox.dds -o models/skybox.vsgb

I've added the resulting skybox.vsgb to vsgExamples/data/models, so update vsgExamples and you'll get this.

Then adding this as the first model to the models loaded in vsgviewer you can add a skybox automatically to your scene. It has to be first otherwise it'll overwrite everything that comes before it in the scene graph.  The neat thing is that you don't have to explicitly create a skybox in your application, you just have to have one on disk and load it.

As a test I ran the vsgdyanmicload example I working with the glTF samples thus (using unix find and xargs to collect all the filenames together and pass them as additional command line args to vsgdynamicload:

    find glTF-Sample-Models -name "*.gltf" | xargs vsgdynamicload  models/skybox.vsgb

The result is:

[Gavin McIntosh]

Hi Robert,

I got the full kit for the Pi400.

The OS was already on the uSD card and it was already in the slot.

Just plugged it in, went through the region setup and was running in minutes.

Only a 16GB uSD and after putting all the development dependencies on it not much room left.

Took out uSD, plugged my USB3 SSD 256GB drive in and was back to developing again.

Should have got a USB to 3.5mm audio adapter. no sound output on the Pi400 except via HDMI.

I am using two old 19" DVI monitors, no sound.

Noticeably cooler with that huge heatsink, that's why overclocking to 1.8GHz is no problem.

You are right about comparing it to a PC, used to have old Celeron Duo with a NV 210 for that.

Died the week I got my first Pi4 1GB, never felt the need to replace it, noisy thing.

Not sure about Vulkan debug, will need to check.

When vsg shuts down there is message saying Vulkan not conformant, testing only.

Need to check it that's there on the 32bit OS + Mesa. 

Have you been watching Zink progress? 

OpenGL via Zink on Vulkan.

Too much to learn.

Regards

Gavin

---

From: vsg-...@googlegroups.com <vsg-...@googlegroups.com> on behalf of Robert Osfield <robert....@gmail.com>

Sent: Monday, February 15, 2021 8:04 PM

To: vsg-...@googlegroups.com <vsg-...@googlegroups.com>
Subject: Re: [vsg-users] Assimp, stbi and tinydds integation integration with vsgXchange

--
You received this message because you are subscribed to the Google Groups "vsg-users : VulkanSceneGraph Developer Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vsg-users+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vsg-users/CAFN7Y%2BUTUTWbEEvuFWj7_WUPq37EShy6Kbkkc%3DoJPb08cGcMfg%40mail.gmail.com.

[Robert Osfield]

Thanks for the info about the Pi400.  One day I'll need to take the plunge with a Pi.  A bit too swamped with dev work to have time to do right now alsa.

> Have you been watching Zink progress? 

OpenGL via Zink on Vulkan.

I haven't been following developments.  OpenGL on Vulkan is really just about giving backwards compatibility for older applications.  To get the most out of the hardware applications will need to utilize Vulkan directly, so this is where I'm focused on - trying to make it easier to utilize Vulkan.

[Gavin McIntosh]

Hi Robert,

 To get the most out of the hardware applications will need to utilize Vulkan directly, so this is where I'm focused on - trying to make it easier to utilize Vulkan.  

Don't stop, been waiting for 4 years to use Vulkan on Pi's, you made it possible to make it much easier.

Had a good compile time last night with the latest code, getting used to how things works takes me ages.

Those dependencies can be a problem, Debian OS's are stable(not bleeding edge).

Would the Compute Shaders be something to look at for doing particles?

It would be almost self contained?

Hmm, a vsg/imgui Shader Toy?

Too many ideas, not enough skill.

Regards

Gavin

[Gavin McIntosh]

Hi Robert,

Got Sascha Willems Vulkan Examples working again.

He did particle fire using the CPU, works on Pi's, yippee.

The Pi400 is much better for compiling on, less time wasted waiting.  

This looks to use Vulkan shaders

https://github.com/nyorain/vulkan-particles

Intel has a few ways to do it.

https://software.intel.com/content/www/us/en/develop/articles/parallel-techniques-in-modeling-particle-systems-using-vulkan-api.html

Stardust demo?

Looking at the OSG namespaces, osgParticles is the one that stands out.

What still needs to be done on vsg to bring it up to osg usability level?

Lighting, animation???

Regards

Gavin

[Robert Osfield]

On Thu, 18 Feb 2021 at 03:13, Gavin McIntosh <g.mci...@griffith.edu.au> wrote:

Looking at the OSG namespaces, osgParticles is the one that stands out.

The only part of osgParticle that is really up to the job is the rain/snow effect - but this is entirely shader based.  The older CPU particle code is a bit of a disaster area, written in the early days of the OSG project with the CPU doing all the work, it's super inefficient and clunky.

These days I think it should be possible to do most particle effects on the GPU, with a small amount of CPU work to coordinate things.  Particle effects are also something that will be pretty domain specific.

Getting comfortable with shaders will really help with opening up what you can do.  Having a vsgImGui based app that allows you to set up uniforms, textures and shaders interactively would be really cool, and allow experimentation and learning, as well as developing effects that could be deployed directly in apps.  I have plenty of my plate in the core VSG so if others want to dive in here then they have my support :-)

 

What still needs to be done on vsg to bring it up to osg usability level?

Lighting, animation???

I think what a VSG-1.0 would ideally be will depend upon different end users. A small number might find the existing code base sufficient, others will see additional functionality as crucial before they see it ready to use, or equivalent another to other APIs like the OSG.

With the VSG project I have gone the route of a more modular set of libraries rather than a monolithic repository for all the main libraries.  The core VSG may reach a state that is good enough for 1.0 prior to other companion libraries, some of these companion libraries may even reach maturity before the core VSG, as they simply have less to do.

For the core VSG I'd like to get positional state supported, which opens the door to easier lighting, shadows, projective textures, and support for multiple rendering bins and sorting of rendering to support things like transparency better.  Right now the RecordTraversal just traverses and records Vulkan commands top down left right order. 

I also want to implement better support for dynamically allocating and destroying descriptors with DescriptorPool resources being reallocated as required, with deeper knowledge of resource management required by users who wish to manage their scene graphs dynamically.

I also want to refine the build so things work better out of the box across platforms - for instance right now some Windows users are hitting up against problems with vsg_glslang.cmake due to cmake configuration issues.

I also want to refine the VSG/vsgXchange integration and filesystem handling to make things more flexible and usable.

Then there is also general refinement of the core VSG API to make sure everything is consistent and coherent.

The VSG isn't just my baby, developed for me preferences, how it evolves depends greatly on the input from the community.

Cheers,

Robert.

[Gavin McIntosh]

Hi Robert,

Don't have much idea what you are doing, so I will leave you alone to do it.

Meantime a vsgimgui based shader toy sounds like something I might have fun with.

Will I need a scripting language built into it?

Make an interpreter in the Compute Shader?

Lots to learn.

Regards

Gavin

---

From: vsg-...@googlegroups.com <vsg-...@googlegroups.com> on behalf of Robert Osfield <robert....@gmail.com>

Sent: Thursday, February 18, 2021 7:28 PM

To: vsg-...@googlegroups.com <vsg-...@googlegroups.com>
Subject: Re: [vsg-users] Assimp, stbi and tinydds integation integration with vsgXchange

--
You received this message because you are subscribed to the Google Groups "vsg-users : VulkanSceneGraph Developer Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vsg-users+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vsg-users/CAFN7Y%2BUn40zySZqbwS%3DB0ZE3PQfVQZATy8Jy%2BWYXKjf8fWp1tg%40mail.gmail.com.

[Robert Osfield]

On Thu, 18 Feb 2021 at 23:45, Gavin McIntosh <g.mci...@griffith.edu.au> wrote:

Meantime a vsgimgui based shader toy sounds like something I might have fun with.

Will I need a scripting language built into it?

I don't think it'll be required, though if the VSG was already integrated it might be one way of tackling some of the functionality. Scripting integration is a whole can of worms.

 

Make an interpreter in the Compute Shader?

The VSG's integration with glsLang means that you can write the shaders in GLSL and leave it to the VSG/glsLang to do the compilation to SPIRV for you.

You'd need an editor for the shaer text, and a way of setting up the inputs - the vertex arrays, uniforms and textures and any #define's.

However, I've not written such a tool before so I'm just guessing at what would be required, others in the community may be more familiar with shadertoy style apps.

[Gavin McIntosh]

Was just looking at the SPIR-V tools, much better integration than OpenGL.

Using vsg/GLSLang would be a logical first step.

See how many of Sascha examples can be used?

Precompiled library of shaders? 

Going to try to see if RenderDoc will compile and work on Pi's.

Going to need all the help I can get debugging shaders.

Found a Vulkantoy, but Windows only

https://github.com/jpystynen/vulkantoy

I have tried every shadertoy on Pi's I could find.

This was fun.

https://thebookofshaders.com/

The Book of Shaders Jen Lowe is an independent data scientist and data communicator at Datatelling where she brings together people + numbers + words. She teaches in SVA's Design for Social Innovation program, cofounded the School for Poetic Computation, taught Math for Artists at NYU ITP, researched at the Spatial Information Design Lab at Columbia University, and contributed ideas at the White House Office of ... thebookofshaders.com

Some early OpenGLES Compute Shader demos on Pi's show tiling artifacts at 65535 particles.

So I'm not sure how well things will work.

20,000+ triangles is pushing the Pi's too.

Godot4.0 has a nice particle demo vid, not released yet.

Fire, fog, smoke and clouds are my main use for particles.

Something like X-planes with Skymaxx clouds might be out of the Pi's reach.

But I won't know until I try, cheat and use 2D billboards? 

Seeing what these little computers can do is what I interested in.

Regards

Gavin

---

From: vsg-...@googlegroups.com <vsg-...@googlegroups.com> on behalf of Robert Osfield <robert....@gmail.com>

Sent: Friday, February 19, 2021 3:47 PM

To: vsg-...@googlegroups.com <vsg-...@googlegroups.com>
Subject: Re: [vsg-users] Assimp, stbi and tinydds integation integration with vsgXchange

--

You received this message because you are subscribed to the Google Groups "vsg-users : VulkanSceneGraph Developer Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vsg-users+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/vsg-users/CAFN7Y%2BUo%3Du%2ByL_OWvrY2M%2BjOL%2BitszJKZRNYFPfObn11MBA1hA%40mail.gmail.com.