Re: NoesisGUI Unreal Engine 4 Plugin
So ! I have to agree. I am a bit lazy so.. Here is today's commit log.
It tells exactly what I did. It goes a bit beyond the classic "this works now !" but well. You might like it.
XAMLComponent:
And yes. There is a basic "auto-build on runtime" function at the moment.
It's still a bit rude as it builds the resources each time a component is spawned
Also, it reads through the xaml to automatically detect if there are any images or any fonts that do need to be build with the xaml!
I am not sure if those two are the only two types of external resources that needs to be built via the NoesisGUI BuildTool. I will check the documentation later, the basic system is here. that's what's important here.
Of course, it's a first pass and I think that I will somehow be able to improve the system later.
Now that there is a XAML loaded in, I will start working on the render target and the material support that will come with it.
First a simple texture and basic material will do it. But I plan on supporting custom materials (that will require of course a few "parametric" options.) to let you free your creativity and make the UIs look more glossy or whatever !
That's still a lot of work. But I think that it is going at a good pace. I might see and release a very first version when the system gets closed up a little more. :3
Erio, Off. o7
EDIT: Added support to the "auto build system" for the ResourceDictionary. (example in ImageAtlas.xaml)

It tells exactly what I did. It goes a bit beyond the classic "this works now !" but well. You might like it.

XAMLComponent:
- Added float parameter to renderXAML function for XAML render update purposes
Removed useless UXAMComponent:: in front of the overriden event in the .h... I don't even know what those were doing here in the first place.. xD
Added FString to store the following datas:- Component name
Parent actor name
xamlFullPath <- absolute path to the xaml file
xamlFolderPath <- relative path to the folder of the xaml
xamlFolderFullPath <- absolute path to the folder of the xaml
buildtoolFullPath <- absolute path to NoesisGUI build tool
providerPath <- absolute path to the folder that is defined as the "root folder" of NoesisGUI ResourcesSystem
xamlContent <- used for dynamic build to store the content of the xaml and read it
xamlFontContent <- used to store the different font that are used within the file for building purposes
xamlImageContent <- used to store the different images that are used within the xaml for building purposes
- Automatically builds the assets before Noesis tries to load them. It's an "auto-build" system.
Minors changes to log systems
Added base code in the renderXAML function to update the xaml once it's loaded
createUI function FINALLY can load a XAML and create a renderer for it !
Changed default AA to PPAA
Changes in OnRegister()- Pre-building and preparing most of the FStrings to be able not to have to do it later
- Component name
- Added GetGameDirAbsolute() function, it return an absolute path to the game folder.
- Added support for GetGameDirAbsolute to be used by UXAMLComponent class.

And yes. There is a basic "auto-build on runtime" function at the moment.

It's still a bit rude as it builds the resources each time a component is spawned

Also, it reads through the xaml to automatically detect if there are any images or any fonts that do need to be build with the xaml!

I am not sure if those two are the only two types of external resources that needs to be built via the NoesisGUI BuildTool. I will check the documentation later, the basic system is here. that's what's important here.
Of course, it's a first pass and I think that I will somehow be able to improve the system later.
Now that there is a XAML loaded in, I will start working on the render target and the material support that will come with it.

First a simple texture and basic material will do it. But I plan on supporting custom materials (that will require of course a few "parametric" options.) to let you free your creativity and make the UIs look more glossy or whatever !

That's still a lot of work. But I think that it is going at a good pace. I might see and release a very first version when the system gets closed up a little more. :3
Erio, Off. o7
EDIT: Added support to the "auto build system" for the ResourceDictionary. (example in ImageAtlas.xaml)
Re: NoesisGUI Unreal Engine 4 Plugin
Hehehe.
Hello everyone, it seems that it becomes to be a daily report.
Here is the commit for today:
XAMLComponent:
I promise you that I do not bite!
That's all for today. It seems way lighter than yesterday's report as I've been working for a shorter time today (slept a little bit more. Sometimes I do need it too!
)
And setting up the command system to be hidden has proven to ask me to use a little bit more my brain than I initially though.
Finally. I've been able to identify a flail in my current system that could prove critical in case of huge UIs.
It seems that the function UActorComponent::OnRegister(), which I chose as point to create the whole system because of it's definition. Is called whenever the component is spawned. which seems optimal! But today I've been able to see and pinpoint the fact that this function was called in multiple cases. As for instance when I modify the path to the xaml in the editor text box.
It's at the same time a super advantage and at the same time a flail. I will have to investigate how this does work.
If it works as I think it does: when you modify a variable through the editor, it re-spawns it with the new parameter. I did verify that earlier with a demo I made using the M50 from Star Citizen. It was calling the "construction script" each time I was changing the color in the editor. (it does not happen in games of course. Unless you decide to respawn it. Which is not natural of course.)
Also, it was building it pretty often when I was switching from my tab with my actor in which one I am testing my component and when I was switching back to the editor. I have to investigate if it's a total reconstruction or if it only calls the function, which might be the case for some reason I am not aware of. (They recommend not to use the function but do not forbid it after all. It might be called at later stages..).
So. I will investigate and keep you updated with what I find and the progress I am making on this!
Once I am done investigating this. Which might be troublesome in certain cases, I will start my work on the render target, streaming to UE4 streaming and rendering in engine!
Cheers!
Erio
EDIT: I apologize for this, again, very long and detailed message!
Hello everyone, it seems that it becomes to be a daily report.

Here is the commit for today:
XAMLComponent:
- Added:
- bool executeDiscreteCommand(FString command); function.
- It replaces the previous call to system to execute the buildTool allowing it not to popup the cmd windows when doing so.
It's much more aesthetic and it feels much better.
Theorically returns false if the command fail to execute.
I will figure out later if this is the return value or not (and if the buildtool does return 0 when it fails to build or some other codes.)
- It replaces the previous call to system to execute the buildTool allowing it not to popup the cmd windows when doing so.
- Modified:
- BuildXAML(FString path) function to return a bool.
- If anything fails to build during the process (including any sub-element such as images, ResourceDictionaries and fonts).
Also added the "modstamp" switch to the command
- Added a security pass on it that takes advantage of the previous modified functions.
It now runs the loading of the XAML only if:- the build previously succeed (which basicaly should mean that the xamls and other resources has been compiled with success)
the .nsb file exists.
- the build previously succeed (which basicaly should mean that the xamls and other resources has been compiled with success)
- If anything fails to build during the process (including any sub-element such as images, ResourceDictionaries and fonts).
- BuildXAML(FString path) function to return a bool.
- bool executeDiscreteCommand(FString command); function.

I promise you that I do not bite!

That's all for today. It seems way lighter than yesterday's report as I've been working for a shorter time today (slept a little bit more. Sometimes I do need it too!

And setting up the command system to be hidden has proven to ask me to use a little bit more my brain than I initially though.

Finally. I've been able to identify a flail in my current system that could prove critical in case of huge UIs.
It seems that the function UActorComponent::OnRegister(), which I chose as point to create the whole system because of it's definition. Is called whenever the component is spawned. which seems optimal! But today I've been able to see and pinpoint the fact that this function was called in multiple cases. As for instance when I modify the path to the xaml in the editor text box.
It's at the same time a super advantage and at the same time a flail. I will have to investigate how this does work.
If it works as I think it does: when you modify a variable through the editor, it re-spawns it with the new parameter. I did verify that earlier with a demo I made using the M50 from Star Citizen. It was calling the "construction script" each time I was changing the color in the editor. (it does not happen in games of course. Unless you decide to respawn it. Which is not natural of course.)
Also, it was building it pretty often when I was switching from my tab with my actor in which one I am testing my component and when I was switching back to the editor. I have to investigate if it's a total reconstruction or if it only calls the function, which might be the case for some reason I am not aware of. (They recommend not to use the function but do not forbid it after all. It might be called at later stages..).
So. I will investigate and keep you updated with what I find and the progress I am making on this!

Once I am done investigating this. Which might be troublesome in certain cases, I will start my work on the render target, streaming to UE4 streaming and rendering in engine!

Cheers!
Erio
EDIT: I apologize for this, again, very long and detailed message!

Re: NoesisGUI Unreal Engine 4 Plugin
After a few days reinstalling the mess that was my computer.. and dealing with dead components.
Here is the lastest commit. Excuses me if I am a bit too tired to put it in right form at the moment. It's raw.
a UTexture2D to create, in a pointer form if I can, then finding the translation between ITexture2D and UTexture2D...
Once that's done. Juste feed the pointer on the UTexture2D with the data from the ITexture2D.
I hope this will be possible. :') *dreams of a simple world* hahaha
I keep you updated.
Here is the lastest commit. Excuses me if I am a bit too tired to put it in right form at the moment. It's raw.
- Added missing includes to get the IRenderSystem from Noesis
Changed createRenderTarget function to add width and height parameters.
Added UMaterial member which is accessible from the editor. It allows to load custom materials for the UI (some work is still to be done about it.)
Now fetching the renderSystem from noesis in the OnRegister function of the components.
Application of the custom material to the component at register (can be changed at any given time by it's accessibility)
Implemented the createRenderTarget function
It allows to chose the resolution, the surfaceFormat and whether this should be a texture or not.
This will be reworked in a very near future commit to add sampling and renderflags instead of "isTexture" boolean.
createUI now calls createRenderTarget to create a renderTarget at the size of the renderer.
renderXAML now execute the Render command and fetches the ITexture2D from the renderTarget.
TODO: Transform the ITexture2D to a UTexture2D.

a UTexture2D to create, in a pointer form if I can, then finding the translation between ITexture2D and UTexture2D...
Once that's done. Juste feed the pointer on the UTexture2D with the data from the ITexture2D.

I hope this will be possible. :') *dreams of a simple world* hahaha

I keep you updated.

Re: NoesisGUI Unreal Engine 4 Plugin
Looks like Xamarin is going to start supporting UE4: http://tirania.org/blog/archive/2014/Oct-23.html
Will be an interesting development
Will be an interesting development
Re: NoesisGUI Unreal Engine 4 Plugin
This indeed looks interesting.
Even though I a not an expert of C#.
Also, UE4 already make use of C# natively, for example in some build files for plugins.
Even though I a not an expert of C#.

Also, UE4 already make use of C# natively, for example in some build files for plugins.

Re: NoesisGUI Unreal Engine 4 Plugin
They aren't making use of it natively, they just use it for some of their tools (primarily UBT). There's no in-engine support for .Net
Re: NoesisGUI Unreal Engine 4 Plugin
Yeah, that's what I was meaning by "natively".
By the way.. Have you any idea of a way to get the pixel array of a ITexture2D in Noesis ?
That's the last step that's holding me back at the moment. ^^
By the way.. Have you any idea of a way to get the pixel array of a ITexture2D in Noesis ?
That's the last step that's holding me back at the moment. ^^
Re: NoesisGUI Unreal Engine 4 Plugin
You can get the underlying handle of the texture resource by casting down (to, for example, DX9Texture2D) to the actual type. That said, I'm not sure why you need to do this? For example, in Unity Noesis is setting the current Unity Render Texture active, then invoking its renderer so no conversion is necessary. All other rendering is done by getting the current graphics context, initializing Noesis with that, then having Noesis push whatever current settings exist and telling it to render (restoring afterwards): in that case it is just rendering to the currently active frame buffer. No need to convert individual resources (you really don't ever want to copy pixel data unless you are writing to file)
Re: NoesisGUI Unreal Engine 4 Plugin
Yup.
That's what I did find out.
So by what you're telling me it seems there are no other solutions.
This is the current code for the render function:
It compiles. But I don't know why my component is not calling it's "TickComponent" function at each frame.
The goal there is to "stream" the Noesis Texture to the one that's used by the material in Unreal Engine 4.
This way, the material can still apply effects on the UI. I guess it will allow for some nice look and feels such as "glass-looking" UI or holographic or whatever.
I will keep you updated when I get a grip on the reason my component is not working.
I will also take a look around the UE4 C# thing with a friend that is much more familiar with C# than i am.
Who knows. I might love it. (In fact. I am curious a lot about the async and await things that can be done ^^)
EDIT: By the way. If the streaming idea is bad. Or the method wrong. Or you're skeptical or whatever. I would be pleased to know what you do think of it.
That's what I did find out.
So by what you're telling me it seems there are no other solutions.
This is the current code for the render function:
Code: Select all
void UXAMLComponent::renderXAML(float deltaTime)
{
NsGetKernel()->Tick();
if (!m_UI_renderer.Null() && m_unrealTexture != NULL)
{
m_UI_renderer->Update(deltaTime);
RenderCommands commands = m_UI_renderer->WaitForUpdate();
m_UI_renderer->Render(commands.commands.GetPtr());
m_noesisTexture = m_renderTarget->GetResolveTexture();
// TODO: get the uint8* from the noesis texture to feed it into the m_textureData
DX11Texture2D *texture = (DX11Texture2D*)m_noesisTexture;
ID3D11Texture2D *d3dTexture = texture->mTexture;
uint32 Stride;
uint8* DestTextureData = (uint8*)RHILockTexture2D(m_unrealTexture->Resource->TextureRHI->GetTexture2D(), 0, RLM_WriteOnly, Stride, false);
FMemory::Memcpy(DestTextureData, d3dTexture, texture->mWidth*texture->mHeight);
RHIUnlockTexture2D(m_unrealTexture->Resource->TextureRHI->GetTexture2D(), 0, false);
}
}
The goal there is to "stream" the Noesis Texture to the one that's used by the material in Unreal Engine 4.
This way, the material can still apply effects on the UI. I guess it will allow for some nice look and feels such as "glass-looking" UI or holographic or whatever.

I will keep you updated when I get a grip on the reason my component is not working.
I will also take a look around the UE4 C# thing with a friend that is much more familiar with C# than i am.
Who knows. I might love it. (In fact. I am curious a lot about the async and await things that can be done ^^)
EDIT: By the way. If the streaming idea is bad. Or the method wrong. Or you're skeptical or whatever. I would be pleased to know what you do think of it.
Re: NoesisGUI Unreal Engine 4 Plugin
This approach is not correct. You don't have two textures, you only have one texture, the Unreal one, that you must bind to make it active. After that, you render the commands. Basically:The goal there is to "stream" the Noesis Texture to the one that's used by the material in Unreal Engine 4.
This way, the material can still apply effects on the UI. I guess it will allow for some nice look and feels such as "glass-looking" UI or holographic or whatever.![]()
1. Bind Unreal Texture Render Target (don't know how to do this in UE4, but should be easy)
2. Execute Noesis render commands.
As I told you in private, I would forget about NoesisGUI and try to clear the texture to a color and see if it works:
1. Bind Unreal Texture Render Target
2. Clear to Red
3. Verify that the texture appears Red in the game.
Once this is working, you can change the Clear step to NoesisGUI commands.
And remember that any step that requires streaming, copying or converting here is probably not correct.
Who is online
Users browsing this forum: Ahrefs [Bot], Bing [Bot], Semrush [Bot] and 8 guests