Announcement

Collapse
No announcement yet.

Unreal Studio Feature Requests

Collapse
This is a sticky topic.
X
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • started a topic Unreal Studio Feature Requests

    Unreal Studio Feature Requests

    Until we launch a proper feature request system, let's use this thread to keep track of requests.

  • replied
    Originally posted by pp_rfrost View Post
    Not necessarily just an Unreal Studio feature, but native two perspective would certainly be appreciated.
    That would be a great feature to add as ArcViz uses that mode of projection a lot. It does have it's limitations in realtime but would be very helpful to have.

    Leave a comment:


  • replied
    Not necessarily just an Unreal Studio feature, but native two perspective would certainly be appreciated.

    Leave a comment:


  • replied
    Originally posted by pf_breton View Post
    thanks david, i sent the comment to our team handling the templates and the twin motion team!
    Looking into this more - it all depends on whether there is a focus on Open VR which would cover more hardware of API specific development, eg Mixed Reality. For example you can run Windows Mixed Reality hardware using Open VR via Steam rather than Mixed Reality only - both are supported in Unreal but don't have parity. I assume that's something the VR team are looking into. Would be great to have a unifying layer when creating applications irrespective of hardware type in Unreal (and therefore subsequently Twinmotion)

    Leave a comment:


  • replied
    Thanks - would be very interesting to see an example and how straightforward it would be to pipeline.

    Leave a comment:


  • replied
    Originally posted by david.gillespie View Post
    Looking into the Datasmith Rhino import, is there any way of exposing this as a runtime function? We would like to be able to directly import Rhino geometry into a built project at runtime. Exposing this functionality would avoid having to do workarounds using OBJ exports/imports with 3rd party extensions (such as ASSIMP).

    I'm sure product viewer type apps would really appreciate this kind of functionality.
    right now the workflow is with pak files. i can send you a small example if you want to explore this

    we’re hoping to provide runtime access of datasmith, it’s something we’re researching. no firm dates in mind yet.

    Leave a comment:


  • replied
    There are three things which would really be neat in UE:

    1.) Texture Arrays would improve the efficiency in some use cases dramatically, since one could use indices to access textures rather than calculate the correct UVs for texture atlasses (especially in some techniques, which require you to use a "random" placing of textures within the atlass in order to avoid filtering issues)

    2.) Dynamic terrain generation

    3.) LOD creation / other optimization features at game runtime (even with a kind of "Loading Screen" to appear and stall the game until the process is done this would benefit some use cases greatly)

    Leave a comment:


  • replied
    Looking into the Datasmith Rhino import, is there any way of exposing this as a runtime function? We would like to be able to directly import Rhino geometry into a built project at runtime. Exposing this functionality would avoid having to do workarounds using OBJ exports/imports with 3rd party extensions (such as ASSIMP).

    I'm sure product viewer type apps would really appreciate this kind of functionality.

    Leave a comment:


  • replied
    Awesome. Thanks very much - most appreciated

    Leave a comment:


  • replied
    thanks david, i sent the comment to our team handling the templates and the twin motion team!

    Leave a comment:


  • replied
    Hi - really think Enterprise is heading in an interesting direction, particularly with Twinmotion and where UE4 is heading with RTX integration. Looking forward to hearing about your latest roadmaps soon on both fronts.

    We've started using Mixed Reality as the Reverb is a great headset from a resolution perspective so very much up our street and with the new Vive Pro as well, we are wanting to make sure everything runs off the same base code rather than building for various headset platforms. Unreal has been great for Oculus and Vive for this however Mixed Reality seems lacking behind. We've noticed:
    • Mixed Reality appears integrated in the VR template but not the Enterprise networked multi-user template. It's a great template for lots of use cases so a Mixed Reality update would be most appreciated.
    • Twinmotion doesn't appear to be supporting VR as the icon is greyed out and the doesn't appear to be any online support any more after the acquisition. We'd love to get this up and running with Mixed Reality too (google cached links even suggest that this is possible).
    Any updates on these fronts would be most appreciated!

    (plus that c# integration we're after! )

    Leave a comment:


  • replied
    Hello, please upgrade the heightmap import system!

    It seems to use 16-bit numbers (65535 values) but GIS data these days is 32-bit (or even 64-bit) precision. 16 bit values just don't cut it with LiDAR, in my case with 2cm vertical resolution and elevation differences greater than 1200m, this word size is overflown. (FWIW I can import a TIN/mesh no problem, was just hoping to use the landscape system, but not if it means using rasters full of redundant vertex data... at a fraction of the vertical resolution...)

    Must admit I'm new to developing with this engine, but Unreal would benefit from linking to GDAL or something so that GeoTIFFs can be imported directly! I found a plugin called terraformpro but how does it get around Unreal's landscape system's internal values being 16 bit?
    Last edited by barf_nz; 06-06-2019, 05:21 AM.

    Leave a comment:


  • replied
    Please update the heightmap import system!

    It seems to use 16-bit numbers (65535 values) but GIS data these days is 32-bit (or even 64-bit) precision. 16 bit values just don't cut it with LiDAR, in my case with 2cm vertical resolution and elevation differences greater than 1200m, this word size is overflown. I can hack-down the quality of the DEM/DSM for Unreal, but that doesn't seem right given the old Assetto Corsa engine handled the LiDAR, but it was represented as a TIN (the Landscape system is raster-only) and used 32b vertex values (TINs are essential for memory management with 32b values, rasters are not an option, and I find it weird that Unreal has this mipmap approach for raster terrain, because it means unnecessarily storing redundant vertex data).

    Must admit I'm new to developing with this engine, but Unreal would benefit from linking into GDAL or something so that GeoTIFFs can be imported directly. I looked at a plugin called terraformpro but this type of functionality is free in blender and how does it even get around Unreal's internal landscape representation values being 16 bit?

    Leave a comment:


  • replied
    Originally posted by Rawalanche View Post

    I can not stress this enough. I am currently visualizing high poly vehicle model which originated from CAD. Everything will be dynamic, no baked lighting. It's about 10M polygons total with lots of tiny pieces. Datasmith wastes majority of import time creating lightmass UVs on this ridicuously complex model just for them to never be used.
    Yes we are working on that problem

    Leave a comment:


  • replied
    Originally posted by jkcameron View Post
    First off I wanted to say great job on the progress thus far with Revit and UE interop. Long time coming and it is finally here. Attending Unreal academy in Raleigh and super excited.

    Autodesk recently added PBR support for materials in 2019.

    I just recently converted our company materials library to reflect these new additions only to find these import into Unreal as Unsupported. Perhaps the Unreal team could modify Datasmith to work with these new materials templates? I was trying to determine what Datasmith didn't like about the new materials; a specific map maybe or a setting but no matter what i change they always import as unsupported.
    This is correct. The revit api gives us new hook to read that data but its something we have to add in our exporter. That is why you don't see them exported at all: our exporter is currently 'blind' on it and we have to write extra code to support them.

    Leave a comment:

Working...
X