Jump to content

Crash in current development branch, on MatInstance::isInstanced()


chriscalef

Recommended Posts

@Azaezel - I noticed that the GuiTSCtrl from which the GuiObjectView is derived has undergone quite a few significant changes for DX11.


I am going to explore the option of creating another entirely new class based off of GuiTSCtrl from which to derive my updated GuiObjectView. This way we don't have all of the necessary GuiTSCtrl rendering stuff(which is used by the actual PlayGui) bumping heads with the needs of the GuiObjectView's rendering code.


Wish me luck!

Link to comment
Share on other sites

Was just about to dig into that GuiTSControl when I realized the 3.8(DX9) version of GuiTSControl was nearly identical to the 3.9(DX11) one. The 3.8 GuiTSControl works under DX9 (no background quad thing), so that's a no-go.


Unfortunately, the issue is much more deeply rooted in the DX11 rendering code(it would seem). I thought I might be able to prevent the GuiObjectView from becoming deprecated, but it appears I am the only interested party.


@Azaezel: If nothing else, could you pass along the information to those mighty tinkerers of the DX11 code? Basically after 3.8 the GuiObjectView can't be rendered without the background quad problem, which effectively makes the class unusable under DX11. It's a shame, I have extended the class A LOT and even built character creation GUI's all around it. Months of development that will forever be stuck in 3.8 and DX9 without the GuiObjectView being correctly fixed for DX11.


EDIT: Further testing is required, but your insight on 'fog' might have just paid off...I was perusing this thread and included your example "restore fog setting" in my GuiObjectView's render code. Again, more to test, but atm it appears this fog gClientSceneGraph's fog data might have been the culprit all along - (At least for GuiObjectViews blended with the PlayGui, still seeing the bg quad problem in GuiObjectViews rendered prior to PlayGui).


EDIT 2: Okay, the fog data was causing GuiObjectViews blended with the PlayGui to show a bright tri in the background. The relevant sections on gClientSceneGraph's fogData in the GuiObjectView's renderWorld() code posted on page 2 of this thread will fix that problem. This makes the class at least usable over PlayGui!! However, the background of the GuiObjectView can still not be made transparent in any case.

Link to comment
Share on other sites

Ah sweet, nice to see others still have interest in the future of the GuiObjectView class! I applied the proposed frustum fix, thanks for the head's up. Still unable to render a transparent background, though at least the fog data fix makes it usable. Basically end up with a semi-transparent light grey background, so worst case scenario I just am forced to layer a darker layer behind it. Much more restrictive than complete transparency, but at least workable ;)


Most importantly, it appears it will be in a solid enough state to polish up and share as a resource with that bright 'fog-tri' fixed. No ETA just yet on that, as I'll need to carve out the time to type out a proper explanation of all the updates. :geek:

Link to comment
Share on other sites

I am envious of your understanding of the inner workings of T3D's code! LOL! I go about as far as to write custom rendering functions within object classes, but that's about it. Any of the more deeply embedded functions, such as those belonging to SceneManager or GFXDevice etc., I just depend on the engine to do work =D


Yea, I hear ya, using the proper viewing frustum to begin with sure does seem like a good place to start. For someone like myself, with limited knowledge/understanding of the 'core' rendering code, I just seek greater knowledge around the subject. Considering all of the updates and changes taking place as of late(specifically around the core rendering code lol), I am taking the opportunity to glean as much wisdom as possible from the transition.

Link to comment
Share on other sites

I have no idea who moderates or works the forums, but it might be useful if common internet methodology is used and threads like this that have an actual solution posted could be locked off and a [solved] tag prepended to the title. I know we have a small community here, but i still think there's a larger quieter community who use the engine and run into issues finding a [solved] link always makes my day a little brighter when searching solutions for problems. :)

Link to comment
Share on other sites

I have no idea who moderates or works the forums, but it might be useful if common internet methodology is used and threads like this that have an actual solution posted could be locked off and a [solved] tag prepended to the title.

 

You are right, this should be posted in here Torque 3D website feedback

 

I know we have a small community here, but i still think there's a larger quieter community who use the engine

 

Very true! :lol: I think the mostly are programmers... :mrgreen:

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...