Sometimes this happens and it is my least favorite part of software development, but: sorry folks, this is not our fault. The problem is with AMD's software. You can ignore that and insist it's our fault anyway, or that we do something about it anyway, and nothing will happen, because it's not our fault and it is impossible for us to fix the root cause.

Ordering in a bunch of expensive equipment in what is normally a hopeless effort is not something we're willing to do. Like I say I would fully expect that to cost us money and result in a dead end - because it's not our software that's broken.

So there's apparently a workaround with an old setting. I guess you can keep using those old Construct releases then. It is a total mystery to me how the old setting could possibly have anything to do with this whatsoever: that setting just sets a flag in the browser engine asking it to reduce the latency of display. What that does I don't know, and why it works around the problem I have no idea, but it also caused a whole bunch of other bugs and problems, so if we bring that back we get all those problems back, which I don't want to do either. As ever, the only way to really solve problems is to fix the root cause, which is in AMD's software.

Your choices are: continue to insist we act on it anyway, which will be fruitless, or actually get in touch with AMD (don't ask me how, we're not AMD) or the browser vendors, either of whom may be actually able to do something about it. Those of you who actually want to see the problem fixed, please choose accordingly.

For those of you who think "just make a 3D engine, how hard can it be?" - food for thought.

For anyone looking for a solution to a major engine issue and not unhelpful misdirection or shifting of blame, there is an addon now available in the Construct Community Discord to deal with the rendering issues related to poor support for AMD GPUs. Created by a third-party developer who has been near single-handedly making a 3D engine that works within Construct in their spare time.

Whether it does need to be Scirra or the users, definitely feels like a huge issue and should all be focused in one thread to report this (assuming amd sorta have a public bug thread we can all chime in on) and not scattershot randomly to the companies.

The issue began occurring after a change in Construct. It's a Construct bug. The likely root cause - a specific change in Construct - has been found and was posted on the Construct Community Discord. Hopefully the community can solve the engine issue, as per usual.

Are you sure that there are not other approaches that could make an integrated 3D engine work, or new APIs that would smooth integration? It seems to me that it ought to be possible to basically import existing Construct objects in to a 3D engine, so you can get the same result as using a 3D layer in Construct, but with that layer rendered in a 3D engine. Therefore the workflow would be the same as it is with addons now - using the Layout View to compose levels, perhaps using placeholders for 3D models and so on - but the runtime renders using a 3D engine instead of Construct's engine. It may be complicated, but I suspect it is possible to do something like that. If it is not possible, I'd be interested to identify why and what APIs could potentially be added to solve those problems.

3D engines are vast and complex pieces of software with a wide array of tools and features. I'm afraid I am skeptical that the requests for 3D features will ever be limited to just a last few. We've done a lot of 3D features now, often with people saying that's the last thing they need, but the requests keep coming. For example more recently, we did implement 3D direct rendering for effects. It was a pretty complicated change and resulted in a few difficult bugs along the way that needed to be figured out, including a regression that made its way to a stable release. But straight away, it turns out that's not enough and there are more features necessary. I'm afraid I am of the view that even if we did what you ask, people would go a little bit further, get stuck again, and then file a feature request saying "the last thing I need is XYZ..."; then if we did that, people would go a little bit further, get stuck again, file another request... and on and on, until we've reimplemented a full 3D engine. We've already gone a fair way down that path and I am getting increasingly reluctant to go further down it. This is why I am instead trying to explore alternative options: if you integrate a full 3D engine, you get all those features you'd ever have requested all out of the box. Then instead you work on ways to improve integration, rather than reinventing a full 3D engine in Construct itself.

Realistically, anyone wanting to do modern 3D with all the bells & whistles would be better served switching engines to something built to handle that task. This is a fine stance to have. But that full feature set isn't something everyone needs, and for many games built with C3 - indie games, with small teams - would not provide benefits outweighed by the events system, the one truly unique selling point C3 has. If users have to resort to entirely separate rendering pipelines and shoehorn them into C3, then C3 has lost all benefits and users may as well use those other more 3D-focused, javascript/web tech-based engines directly, because at that point, doing it in C3 is more of an impediment than a benefit, and WYSIWYG-style editors already exist for those other gamedev tools.

A majority of the efforts needed to have working - if a little retro, which is in and selling games these days - USEFUL 3D in C3 is already done. There are multiple examples above, including of projects that have already been commercially released, or will be shortly. Some of it required engine hacks to get working. The idea is that, moving forward, those hacks would no longer be necessary with SDK v2. That's the whole point of this discussion and has been since long before the announcement of a revised SDK to, ostensibly, deal with the current situation of engine hacks being required to do things developers need to do for their C3 projects that feature some amount of 3D content - even in mostly 2D projects with small 3D elements, or in project with more 3D visuals but still strictly 2D gameplay - the kind of thing (currently, with a few hacks) C3 already excels at.

What exists here, in this thread, is an "out" for Scirra. 3D can be done by those interested, capable, and dedicated to doing so, with comparatively little - much less than implementing full 3D yourselves - effort on Scirra's part. It has already happened. That door is not closing again. This is unlikely to change unless Scirra goes out of its way to actively - and maliciously - prevent end users from doing so. The remaining question is whether Scirra would like to make that easier or harder for some of its paying end users - power users - who will do it regardless.

Moderator note: this comment removed for the reasons described in this post. Please see the Forum & Community guidelines.

Isn’t no official response fine? Ashley only responds quick to shoot down an idea. We could also extrapolate what the possible reply could be based on previous replies on this topic. Typically we never know something was being worked on till it was basically done. There’s probably a reason for that. How many times has someone started working on something and for whatever reason couldn’t get it working? He could be working on something or doing nothing related to this.

So, it seems a non-public response was made, likely to avoid the obvious and deserved community - what's left of it - fallout.

For those wondering, the short version is: it would take effort, so no, despite it obviously being possible, given we all have eyeballs to see it working with a comparatively simple hack made by someone in their free time.

Fantastic work as always Mikal.

We get so many feature requests it's difficult to even respond to them all, especially when they are long and detailed.

You should already be able to choose individual images per 3D shape instances using a sprite in a container. If you are proposing something to improve performance, you should include benchmarks - guesswork does not make for a good case.

Ashley, I have to say if you're going to respond to something in the future, please consider taking the approach of reading at least a little of it first instead of just posting different variations of the same non-response that makes it very obvious you did not. I'm sure this is where you'd like to express some frustration in not getting things 100% your way, but it really is very frustrating for end users that it seems best for anyone who's not an absolute beginner or has used any other software in their lives to just nope out of these forums and never, ever attempt communication with the people running them or developing the product.

I wish I could say that is just my position, but it seems to be the general consensus amongst a majority of experienced users, quite a few of which told me my original post was a waste of time because we all knew what your response would be - and was, because it's that predictable.

On a related note, these claims you made about working with Safari/Apple on iOS - which I took the time to read - mostly apply to dealing with Scirra in any fashion as well.

assets.publishing.service.gov.uk/media/6229ae538fa8f526d520d0b8/Scirra_Ltd.pdf

This line in particular from your writing stands out:

"It's difficult to objectively measure software quality and demonstrate that Safari is inferior in this regard. However to those working in the field there is a clear quality difference..."

Oh, that second sentence. What a bugger. Consider how would you - and do, since you basically just did it in your reply - respond to such a line from a Construct user.

Difficult to deal with, non-responsive to user needs, new developments (that would be useful for users in a real-world scenario) etc. Sounds pretty familiar to us. It's interesting that you believe it's a problem when you personally have to deal with it, but not when your users do.

Take the above as some paying user insights to seriously consider as you're looking to grow your user base, and I would imagine revenue stream, in ways that don't involve just raising prices and the subscription triage they invariably cause. Because that's what they are.

Good luck.

You'd need to repeat all the properties for all possible objects that can be set as faces (e.g. sprite animations, Tiled Background offsets, etc.), including all the conditions/actions/expressions to access them, all of which duplicates all the existing features in the other objects. Which is why it's designed to just take them from a corresponding instance.

Ashley

Not to necro too old of a thread, but I found this post while running into a similar issue where I'm creating Sprite objects during gameplay that I want to use with more than one 3D Shape object, and the way it currently behaves is somewhat inconsistent with how picking/referencing other objects works in other areas of Construct.

TL;DR version:

Being able to manually pick the specific Sprite object to supply the images shown on multiple instances of 3D Shape's object faces would be useful and potentially help performance when there's otherwise lots (potentially thousands) of instances of the same Sprite object floating around that don't really need to be there if this capability existed.

Details:

If I'm creating the Sprite in a more top-level event before creating the 3D Shape - which generally means that's the most recent picked object Construct should know I'm referring to, and C3 does appear to keep track of the most recently-spawned Sprite throughout the process I'm describing - when I assign a Sprite object to the faces of the 3D Shape, it's picking a random Sprite instance if I create more than one 3D Shape object after creating the Sprite object.

This is consistent with how you're describing the intended behavior Ashley but if multiple objects are using the same image (and always will) it seems like if I either create a sprite during a higher level event or pick a sprite by IID/UID, then that should be the object that's used as a reference for the 3D Shape. Otherwise there's a lot of unused objects floating around the layout and I have noticed some (however small) performance impact when doing it this way, and that impact can add up.

As an example, here's a procedurally generated layout where if the walls are only a single 3D Shape object on each "tile," Sprite/3D Shape pairs are correctly assigned:

If there are multiple 3D Shape objects created at each "tile" to create higher walls (no, scaling the z Height of a single 3D Shape object isn't an option for other reasons) then the wrong Sprite objects are picked and the results aren't quite as intended:

Since each 3D Shape object is using the same image as other 3D Shape objects on the same "tile," this seems like something that should work and also reduces object count. What could be even more efficient is creating only enough Sprites to represent every image/animation, and then be able to re-use those where needed to apply images to the necessary 3D Shape objects, reducing the object count - and improving performance, as there IS a verifiable impact - even further. Mikal has implemented a similar solution for his 3D Object addon and it works wonders around saving memory usage and eliminating the need to have multiple copies of the exact same object floating around eating up CPU cycles and memory.

As an example, all of the 3D Object in the image below - the terrain is a DrawCanvas mesh and uses only standard C3 features, the trees/rocks are what I'm referring to - reference the same "prefab" object that has the model & texture data. Similar to the official 3D Shape object, deleting the original would also remove it from every instance of the object, so this 3rd-party addon is already working in a way more in line with how the rest of C3 functions than the official 3D Shape object. It would be nice to see parity for the reasons described above, and this would also bring the 3D Shape object in line with how (I think) people generally expect C3 to work.

We're a small team with limited resources. I say that a lot because it's true. I'd totally do absolutely all the things everyone ever mentioned if it was possible. Unfortunately we are bounded by the laws of physics. It's not that we're ignoring people, it's just that we get asked to do about 10x as many things as we can actually get done.

We do lots of things for lots of different reasons. Construct Animate is an effort to grow the business, and if it works out, it could permanently increase our capacity to develop Construct and get more done. 3D Audio was pretty much only done because browsers already implement a 3D audio engine, and Construct was already using it, but not letting you control Z positions so it was locked in to a 2D mode; we just added the ability to set the Z positions, which was straightforward.

Some things sound easy and turn out to be extremely difficult and time-consuming. Some things sound hard but turn out to be easy. Some things we do directly because of user requests, and others because we think it's the right direction for the company. There's a lot going on, and I can see how it might not always seem consistent. But we're always working hard to improve Construct, and no matter what we work on, we'll never cover absolutely everything that we're being asked to do, because there's just far, far too much we're asked to do for it to be remotely possible for us to do it all.

Hey so I seem to recall the switch to a subscription model being pushed as the best way to grow the team. It's now years later, and it's not like there aren't highly skilled developers both using C3 already and elsewhere.

So... yeah. That particular lines of excuses has lost any effectiveness it may have once had. Maybe time to come up with a new excuse, the current one has aged like fine milk.

I suggest blaming the convoluted integration of javascript into a "you don't have to know how to code" engine, that is significantly more complex to use than just using javascript with any of the number of straight javascript engines that can do more, more easily integrate with external libraries, and are also free.