Ambiera ForumDiscussions, Help and Support. |
|
|
|||||
|
So, many moons ago, back when Lightwave was being bought over and the hope for a bright future for this amazing legacy industry-proven 3D modeling and animation program was up and up, I proposed the idea of using a modern game engine as the rendering engine. https://www.youtube.com/watch?v=... And I have been seeing lately here that more and more people are talking about source code access, and it makes me wonder... So what even if you have the source code? The rendering pipeline is legacy; coppercube's strength is its ease of use. What if Godot is used as the rendering backbone and the coppercube's editor and way of doing things is overlaid on top of it? I don't know...just a crazy thought. Probably nothing will come out of this crazy thought. |
||||
|
Idea's are what bring forth the future. Good or Bad... Keep them coming people! It's okay to think. 
|
||||
|
Thank you for being kind in your respond. |
||||
|
My suggestion is Coppercube...if the source code for studion version was re-written into flutter. The API connect as flutter source code instead of Android studio source code. Then Coppercube can make games into Android and IOS. |
||||
|
It's not a bad idea, the copper cube UI is great and usefull, but the rendering engine is ugly and outdated... |
||||
|
ThreeJS in coppercube cube...
|
||||
|
Guest wrote: It's not a bad idea, the copper cube UI is great and usefull, but the rendering engine is ugly and outdated... I have a hard time agreeing with this, because I 100% think the engine can output some stunning visuals with enough work. The only thing which really holds it back is the lack of a decent culling system (Robo fixed this), and the built-in lightmapper could stand for some serious optimizations. Smaller things like being able to just use normal maps on lightmaps and animated meshes as well would go a very long way in boosting a game's visual fidelity - same with an SSAO shader. You can fake AO with clever use of planes which have a black gradient texture, and you manually place / stretch them in spots where AO would naturally be, but that's time-consuming. I heard Threadripper CPUs are insanely fast at calculating global illumination in the editor. I want to upgrade to that someday, but money... lol. |
||||
|
Guest wrote: It's not a bad idea, the copper cube UI is great and usefull, but the rendering engine is ugly and outdated... not if you know how to use it wink wink |
||||
|
I was sad to hear that Niko will never release the Editor source code to the community as this is needed to properly incorporate some new features that will work with the Editor before you save your final exe. Perhaps the new update will actually load and run the new source code from new binaries within the Editor itself - yet to test out....I certainly hope so as if it only takes the new binary code when writing into the exe file and not when running the Editor would be a fairly useless addition as we can already do that and anyone can use it - even on the free version. Without having access to modifying the Editor code, CopperCube has a very limited life ahead IMO. You need that to save new data which didn't exist previously otherwise it will crash (from my testing on adjusting the source code). In short - if new features cant be added into Editor itself without waiting 2 years for an update then either use it as it is or maybe try another game engine like Godot. I don't see any other solution actually apart from certain things that will run just fine during runtime like occlusion culling and dynamic lightmaps and things like that - they can still be nice additions.. |
||||
|
There is a recent conversation I had with Niko that he might actually allow new API and source code functionality to work within the Editor itself.... such a thing would be huge benefit to the Editor and the community...lets hope it pans out to work that way... |
||||
|
|
){kind=link}