Jump to content
  • Advertisement

Jozin

Member
  • Content Count

    27
  • Joined

  • Last visited

Community Reputation

105 Neutral

About Jozin

  • Rank
    Member

Personal Information

Social

  • Twitter
    @pitchuggah
  • Github
    pitchuggah
  • Twitch
    pitchuggah
  • Steam
    leninque

Recent Profile Visitors

2034 profile views
  1. Because the old-school fps game couldn't be thought without cool music and this is what I'm striving to achieve, so I wrote some cool metal music years ago and now I was like, "Hey, what if use some of this for fight/battle music", so below is the some of tracks I've plannig to use, the first track I guess for underground battle and the second for epic fight:
  2. Jozin

    Devlog #1:My Eyes

    Hi everyone. It seems new UE eye model requires specific UV coordinates and mesh, so custom shapes with custom uv / or no uvs was not possible .. until this moment. Suppose we have some kind of nice looking eye shapes (for test purposes I took the ones from the Emily project), unfortunately its uvs not corresponding to those delivered with the UE eye model, also the eyes have custom orientation, etc. So we have at least 3 possible solutions here: 1) rip off the eyes from one of UE/paragon characters 1) fix the uvs in any modelling app 2) implement some kind of automatic uvs with adjustable rotation/scale of iris. Despite of simplicity of two first approaches the third one gives us much more. And its not so difficult. The solution is to generate tangent basis and uvs in the shader/material itself. And this is not mistake, in the several cases transform from tangent to world space could generate artefacts due to discontinuities on original uv space, just like this: The original uvs left below have discontinuities at poles unlike from uvs from UE docs (right below) The result for eyes without any uvs you can see in the header, the rotation and scale of uvs is fully adjustable
  3. That polite words - all this is very good, but in that case - feedbacks is only means to say something in the void and most likely - false. So it's very pleasant to hear complements especially for our egos but initial essense of any debate just attempt to find out the truth and essence of any feedback is another way to set the faults of your work from real listeners. If someone evil says bad things about your art -its another cause to think - what's going wrong with this and look to the things from may be negative but nothing more then another point of view and good opportunity to improve you work I guess
  4. Jozin

    Heli project

    Bee cargo vehicle ear ly concept, more at https://www.artstation.com/contests/nvidia-metropia-2042/challenges/60/submissions/43131
  5. Jozin

    Heli project

    Thanks for your feedback but I recall to mention one interesting fact: the engine was especially made for heli/flight sim and doesn't (at the moment) expose features like face animation, sss shaders etc. On the other side it can handle very large spaces via megatextures-like approach. But this time I want to make a fps game and not likely it will demand a lot of space to explore, so now it's more crucial to produce some hq 3d assets in corridor-like environment, that's because I've started to learn zbrush and substance painter)). In all the cases the stuff I'm going to produce will be placed here or on the project page.
  6. Jozin

    Heli project

    Hey dude, strange things happen. The engine was originally written with ManagedDX with sm3.0 (dx9) and uses alot of raytracing/screen space stuff, I've planned to port it on SharpDX and dx12 but it seems it not in active development at this moment. For me there is only 2 viable options: 1) rewrite it to C++ and 2) modify other engine to fit the needs just like UE but wait.. there is 3rd option: leave it all as is and do make the damn game)) Relating to you second question: yes there is some simple collision detection/ helicopter physics
  7. Jozin

    Heli project

    Water shader in progress
  8. Jozin

    Heli

    fps
  9. Jozin

    Heli project

    Here is my game project from 2016. Being just a simple helicopter/environment sim it features its own engine also written by me, but I've desided to give it another shot, may be transform it to full 3d game, maybe port it all to unreal engine. Any feedback and suggestions are highly appreciated Close look including dynamic clouds and rain Volumetric clouds test
  10. Hi all, recently I've tried to implement macro support for my effect system. It is working using the d3deffect class. We have some count of *.fx files for each type of entity( atmospherics.fx, water.fx, meshes.fx etc), so if some #ifdef #endif brunching is happened for the some particular technique, we need to recompile all effect (many techniques)/ Now what I wanna do: 1) split each effect to many ones, such a single technique equals one effect, (<name_of_effect>_<name_of_tech>.fx) 2) put common functions separately to the outer *.fxh file, will be included to the each of pointed above effects so if we need to recompile something, we are doing it at "technique" level, not all effect Is it right, may be someone has implemented this alghoritm, are you? Now second, the next common used idea - do not use effect files and d3deffect functionality at all. pro - we can work at shader level cons - not easy to implement, we need deal with many registers, and set it manually (some people assigns registers explicitly) Now the second question - what method are the best? What approach do you using in your projects? Thanks
  11. Hi all, recently I've tried to implement macro support for my effect system. It is working using the d3deffect class. We have some count of *.fx files for each type of entity( atmospherics.fx, water.fx, meshes.fx etc), so if some #ifdef #endif brunching is happened for the some particular technique, we need to recompile all effect (many techniques)/ Now what I wanna do: 1) split each effect to many ones, such a single technique equals one effect, (<name_of_effect>_<name_of_tech>.fx) 2) put common functions separately to the outer *.fxh file, will be included to the each of pointed above effects so if we need to recompile something, we are doing it at "technique" level, not all effect Is it right, may be someone has implemented this alghoritm, are you? Now second, the next common used idea - do not use effect files and d3deffect functionality at all. pro - we can work at shader level cons - not easy to implement, we need deal with many registers, and set it manually (some people assigns registers explicitly) Now the second question - what method are the best? What approach do you using in your projects? Thanks
  12. Hi! I've developed a pretty simple shader system to manage my own needs. The system is a big effect(fx) file with couple of techniques in it. To recompile any partial function we need recompiling the whole file, so I invent this approach: -in time of reloading we're creating effect compiler from file(new file) -extract vertex and pixel shaders code from it - compare it one by one with previous saved shaders -if we're having differences, then recompile the modified shaders with CompileShader function -after the beginPass we check if modified shaders are available for this techinique and pass , we're setting it with device functions(SetVertexShader and SetPixelShader respectively) Now the question: what is wrong in outlined alghoritm, maybe I need to set constant table? So in several cases all works, but in other - not. How to link other shaders then it's suitable by the current effect in effect.Begin effect,End scope? And what the work does the effect(ID3DXEffect ) in this functions?
  13. Thanks for paper, its very interesting but do not meets interests i'm going to follow. (I'm talking about other mask - ground mask) First, the main problem i's encountered is to cull empty places. Mask(grayscale texture) I'm using for it does not suitable to go on the cpu side. In NVidia's paper this operation goes on cpu(seeding foliage) in offline in the common case(casting numerous rays to found the right place for seeding). Because I do all the work with masking on gpu, giving the large blocks near the camera, and cull it using mask texture with texkill and putting it to offscreen
  14. Exacltly this approach i've tried to implement on gpu side, but the culling and masking are applied on gpu, -> if we create small chunks near the camera, we do not manage it to cull parts smaller then some predefined size(64x64 for example). The main problem is how to cull wasted triangles BEFORE it'll be culled on the gpu side
  15. Thanks I will try it
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!