Polygallon's Forum Posts

  • Polygallon

    You sound completely asinine, but you know no offence pal.

    Maybe I got a little out of hand, but I hope you understand that all I'm after can be as simple as a "hey guys, kinda busy with everything right now, Q3D is still being worked on." I didn't mean to sound 'completely asinine' with my post - I just threw all scenarios I could muster up into a list and hoped something would stick. Personally I hope he's been contacted by Ashley, though more realistically he's just busy with life as you said. Maybe I'm just a little too hyped over Q3D 2.5.

    I realize this isn't my personal blog (not that I have one). See my old post here (It's way too long): https://f.lewd.se/72g6m7_2016-08-25_17-37-30.txt

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • anyone knows how to put a video as texture ?

    You could possibly convert the video into still images and animate a Q3D model's texture with it that way, while optionally playing the extracted sound from the video simultaneously. This is to say, of course, that you're willing to put such a heavy load on memory and/or said video is low in frame rate, short in duration or small in resolution. I could see this being used to, perhaps, simulate a TV set - but in that case other work-arounds could be achieved.

    The most direct approach could be if you showed the video through the media object (probably in fullscreen on another layer) once the player has interacted with whatever is supposed to show a video. Or, if the video is simple in nature (mostly text or a mainly static news presenter), it might be possible to "fake" it in the form of a model with morph animation (since a pseudo-2d animation in actual 3d space is most likely more memory friendly than a long string of frames) but that's a lot trickier.

    If neither of these options sounds particularly inviting (you want a video shown in real-time on a plane in 3d space) you might find more luck in other more robust 3d engines or setting your bar lower.

  • Where is updates?

    Bloody good question. I'd pay to see some progress reports let alone get the final 2.5 update.

    C'mon, this isn't valve we're talking about

  • QuaziGNRLnose If you're still working on this plugin, I strongly recommend working on getting shaders working because that would be ever so sweet.

    I agree with this.

    Are there any news regarding the next update? Progress, delays, stuff like that? It would be nice to know how close we are to an update.

  • Polygallon

    slopes aren't a bad idea, but adding a collision shape to the physics engine is actually *VERY* complicated [...]

    Something like this?

    Thanks.

    Hey, I know you're drowning in questions, but I gotta ask. Can I make a 2.5D game with this? I mean pre-rendered backgrounds with parallax scrolling all that regular C2 stuff but with 3D characters?

    Also can I make unshaded characters but tint their colors? Like when a cartoony flatshaded character goes into shadow and goes dark and tints to the colors of the shadows.

    Yes, you can.

  • slopes there is no need for them ... u can take a cube resize it and change its angle .. and thats a slope if im not talking of a different thing

    Yeah, I thought so too, turns out there's a lot of fidelity to a slope made like that - especially if you're trying to make something tile-able. It's not enough to turn a Q3D Model with a box collision shape 45 degrees on the X or Z axis and call it a day. Overall, it's just a nice and helpful thing to have as a collision shape. I wish I knew javascript so I could add it into the Oimo behavior myself or something, but sadly that's not the case. If it is overlooked, well, then I guess the next development stage for me is filling out tables of rotation and position offsets for ca 40 differently scaled feign-slopes through trial and error... Which kinda reminds me about the concept of eating sand.

  • *Unnecessary comments about struggles regarding the apparent unavoidable instability and finickiness of multiple collider shapes*

    Pardon, I've worked on my project now over the holidays and constructed a semi-reliable work-around.

    In past posts I may have asked for redundant features to this plugin that could be achieved otherwise or weren't exactly necessary for the scope of Q3D. However, despite my forthcomings, there is yet one more thing I urge you to consider adding in regards to Oimo collision shapes - while still respecting your previous statements about it.

    In terms of Oimo colliders - we've already got cubes, spheres, cylinders and (composite) capsules. I would also like to see slopes on that list. They'd scale much like cubes - and in theory they should also be less expensive than cubes, correct? Should be less expensive than cylinders anyhow. Slopes would be greatly useful for developing platformers, racers, the "physics ball" type games, some far-fetched abstract low-poly fps ... anything really that could benefit from ramps. So, may there be slopes in the future?

    Lastly, happy holidays (or happy continuation as we say it where I live) to everyone here!

  • Collision "meshes" are too computationally expensive in JS, and wouldn't really be viable in a game. Already the collision system is difficult to get good performance out of, and it's pretty highly optimized with spatial hashing.

    Alright, well, I guess that makes sense.

    The oimo behaviour however does support compound structures you can setup through events, although it can be pretty tricky to work out positioning the pieces at first.

    I'd say. This is where I am having most trouble atm and where mesh colliders would help immensely. Making complex collision structures would be a whole lot easier if the model didn't keep offsetting itself, trying to center into the middle between every collision shape added - even when the model's fit and center settings are at "unaltered". I don't want to be stuck nudging fractions, and adding unnecessary collision shapes to offset every other collision shape, just to make a complex model work. Is this easily fixed? Is there a viable work-around? Is there already a setting for this to stop? I'm asking since I am essentially stuck because of this.

    Additionally, being able to access information about the collision shapes themselves would also be nice. Expressions such as " Get shape X size of 'DefaultShape0' " and the like. Maybe even loops like "For every collision shape" although that's not as necessary.

    (...) and the capsule collider is actually a compound object as well!

    Interesting. I was wondering why I couldn't assign the height of the capsule collider, turns out it's probably because it's a hardcoded cylinder with two spheres. Aight'.

    And no worries about the color thing

    I await the next update with high hopes!

  • Hey, I'm wondering if there's going to be a more extensive collision support in the future of Q3D?

    I would like to see the ability of assigning collision meshes to Q3D models and their Oimo behaviors. Would that be possible?

    Also, some quick bug reports off the top of my head:

    * The expression in "Q3D Master: set background color" flips the R and the B values. So if you assign the RGB value to be rgb(255,0,0), the result will be pure blue.

    * The shadow cam in spot lights and directional lights seems to "cast shadows on itself", seemingly based on distance and pitch to each object it casts the map on. I wasn't sure what was actually causing it - and even after experimenting with every shadow map value available at run-time, it's still quite apparent.

    Thanks and keep up the good work!

  • Ethan

    As someone who've learned Q3D via trial-and-error and some frustrated educated guesses, I've had no actual major problems understanding nor relying on Q3D to do it's job.

    Obviously documentation is a big plus (and something I also would've liked in the beginning) with plugins like these, but it is in no way mandatory. Quazi has created something that wasn't supposed to be supported by Construct 2 in the first place - alongside plenty of update information every time he adds onto it, and taking his time to support Q3D users with their questions in this thread. I've read through some pretty nasty and naive comments here, and Quazi always seems to be able to answer in a professional and patient manner no one should take him for granted to have. I believe we're forgetting that he's just one person (talented one at that) whom at some point decided to make an excellent plugin and then went out of his way to keep it stable and feature-packed by the best of his abilities, and I commend him for every second he spent doing that.

    His brother recently released a game that I've been looking forward to (Towerclimb) - and even then, Quazi has every right to be busy whenever he likes to be. This is not a commercial product backed by tens of people, it's one hobbyist pulling the strings and asking for the equivalent of three substantial dinners in return. No pay-per-month bullshit, no pay-per-update shenanigans - he's as humble and as reliable as can be in my eyes. And with that, In my opinion, you should be satisfied with what you bought since the only problem here is documentation, something he has since proven is on it's way.

    He could've just released the first version and leave it at that, but he does try to keep it an understandable, working, semi-regularly updated plugin for something that otherwise would require a java programmer to achieve. Going the other more painstaking way around, Playmaker for Unity costs $65 as of writing - and should give you enough to emulate Construct 2's event system in a fully-fledged €ommercialized 3D-engine alongside probably plenty of documentation.

    So please, respect Quazi's private life and his personal will. When he wants and has the time to work on the plugin, he will do that.

    I got here to ask about how to render a Q3DSprite's magnification filtering by nearest instead of linear, but was pleased to see the plugin is still in progress and hoping it'll be in v2.5. Until then - I will work with what I have, refer to this thread for common answers and just ask questions when I'm full-on 100% stuck. For more beginner documentation than what Quazi just linked, you may also want to check out http://3dswing.com/ or CTRL-F on the first post to scan through update information with keywords. Otherwise, some of the most confusing little problems for me has had the most simplest of answers in places you don't even think about looking in. If you're curious how to achieve something specific, you can also look at the demos referenced on the website I linked or on the first post, otherwise you can always try it yourself and learn from experimenting.

  • Oh man ... Wow that's embarrassing

    Thanks blackhornet, this thread should be removed.

  • *me being silly*

  • I noticed that some of the shadow light's shadows disappears in certain areas, and I soon realized that the culprit was the sprites with the shadow caster behavior being automatically culled/not rendered when outside the screen. I understand that this is for optimization, but how would I turn this off for individual sprites? I wish to have the shadows be visible (rendered from the affected sprite) even if the shadow casting sprite isn't currently on-screen. Thank you.

  • Sup!

    Before anything else: QuaziGNRLnose deserves major credits for maintaining Q3D, granting sweet features (skeletal animation?! 3D physics?!) and also for just being so friggin' amazing. I'm a having a ton of fun playing around with Q3D, since it's surprisingly user friendly due to it's design and integration with C2's interface. All in all, I'm very pleased with the extension

    Now, I'm working on a project (of course) with Q3D, and I'm wondering ... How would one go about achieving cell shading? (Simple toon shading, that is - outlines or not)

    I've noticed the Shader property below the Material Type property in a Q3DModel, asking for a .qfx GLSL file - But what is that, exactly? Google is kind of inconclusive when it comes to answering that, could you point me in the right direction if I'd want/have to write a cell shading .qfx myself? Or is there a place where such finished, default GLSL shading algorithms can be acquired/downloaded premade in .qfx form, and be usable for Q3D?

    Thanks in beforehand

    edit: After reading the above post, I guess I should wait until a later update before I try getting cell shading to work, or is there something I could test in the meanwhile?

    How's the work regarding extending the .gfx capabilites going, if I may ask in a patient manner? Cheers!