I have a feature request: the plugin currently only imports the RGB channels for the vertex colours. Would it be possible to get the 4th channel too (alpha)?
It would be really useful to be able to have a fourth data channel in there, because it could be used to drive certain effects in the material. Just a thought.
Iâm experimenting with something that might end up using the alpha channel for other purpose but if not, then Itâs certainly possible and I will add it to the next release
Depends on what youâre trying to achieve. How many axes of rotation? Random or specific rotation?
For random you can use things like world position / color component etc.
Hey guys just out of curiosity, what would you use to export a point cloud that has information stored in an alpha channel? This is in regard to @anonymous_user_a786c057 earlier question for @.
Hey guys just out of curiosity, what would you use to export a point cloud that has information stored in an alpha channel? This is in regard to @anonymous_user_07ba773b earlier question for @.
[/QUOTE]
Iâm producing my point clouds with Houdini, so itâs just a case of adding an alpha channel manually with whatever data I want. If you wanted to add an alpha channel to a point cloud you had in CSV, that would be pretty easy to do in Houdini too.
Iâll have a look tonight and see what causes it.
You mentioned it only happening occasionally - as in, the same project will sometimes build without problems or that only some projects suffer from it?
Some control questions:
Are you using the v0.4.2?
Is the issue reproducible in fresh, empty project with just the PC in question?
Awesome job on this plugin. Itâs going to be a huge help to our project, so thank you for sharing.
I just thought I would share with you that I was actually able to compile and run 0.4.2 as an engine plugin by doing a clean build of the full UE 4.18.3 source using the Unreal Automation Tool. However, there was one compiler error that was resolved by changing the include on line 8 of PointCloudFactory.h from âPointCloudRuntime/Public/PointCloud.hâ to just âPointCloud.hâ.
Also, when using the non-unity build to compile our game (this time with the Point Cloud as a project plugin rather than an engine plugin), there are a few compiler errors due to missing #includes:
PointCloudStatics.cpp needs âFileHelper.hâ and âRuntime/Core/Public/Misc/Paths.hâ
PointCloudSection.h needs âPointCloud.hâ and âRuntime/Core/Public/Math/UnrealMathUtility.hâ
None of this is a big deal and probably wonât be noticed by many people, but I figured I would let you know what we found in our testing. Thanks again!
Some people reported compilers complaining about missing includes - not entirely sure why it only happens for some. Will add them just in case, as to avoid potential issues - thanks!
Interesting find with the engine compilation - was it a clean 4.18.3 source build?
Version 0.5 turned into a much bigger undertaking than originally anticipated. The internal data structure as well as how itâs send to the GPU have been completely redesigned to allow for much more scalable and flexible approach. These changes should also make the transition to full streaming and background rebuilding in the future much easier.
The clouds are no longer being split into individual sections, which use their own, self-contained render data and LODs. Instead, an adaptive octree division is applied and the LODs are partially constructed and handled at runtime. Gone are the section size setting and worrying about draw call count - the whole cloud will now use as little draw calls as there are LODs
My guess is Unreal isnât always consistent with which source files it lumps together when generating the giant combined cpp files for the unity build, so most of the time the missing includes get included anyway, but occasionally theyâre split between separate cpp files.
Yep. I just checked out a clean copy of the 4.18.3 engine source, put the Point Cloud code into Engine\Plugins, generated the project files, and then ran BuildGraph via the Unreal Automation Tool (RunUAT.bat).
Quick question for you - When rendering our point cloud as points, the points seem to get culled out of view rather quickly when you try to get close to them in both the editor and the game. I played around with the LOD settings a bit as well as some of the Unreal rendering console variables, but they didnât seem to have any effect, and I havenât seen anything in the code so far that would be causing it. It doesnât appear to be an issue when using sprites as the render method though. Any ideas?
Sounds like youâre describing near clipping plane. Sprites would appear to be less susceptible to it simply because they cover bigger area of the screen and so you donât just see them go all of a sudden.
That was my first thought as well. The near clipping plane is already set to 0 for our player camera, so I didnât think there was much more I could do to adjust it.
Below is a small sample of what to expect from the new rendering approach. Keep in mind that this is still very much work in progress and far from properly optimized.
I have 2 point clouds in the same coordinate system and would like them to line up when I bring them into UE with the plugin. But when I insert the point clouds it goes to the mouse coordinates, making it difficult to line them up perfectly. Is there a way to have them appear in the level according to their point coordinates?
Import both clouds with no transformation applied, drag them both to your level, then set their Location to 0, 0, 0. The downside to this approach is they may end up with a very large offset from the levelâs origin (0, 0, 0) causing weird movement.
Import the clouds as First Point or Center, then calculate what should be their relative offset in the chosen case and assign those offsets using the **Details **panel. For example:
Letâs assume that we have clouds PC1 and PC2 and that their respective first points are **519287.471, 195777.342, 97.635 **and 5****19213.366, 195981.924, 98.681. Assuming you import them using a scale of 100 their respective Origins will be: **51928747.1, 19577734.2, 9763.5 **and 5****1921336.6, 19598192.4, 9868.1. To calculate their relative offset you have to subtract PC1âs origin from PC2âs origin, like so: